| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| | |
Improve error message for circular dependency case
|
| |
| |
| |
| | |
Closes #3738.
|
|\ \
| | |
| | |
| | |
| | | |
Clarify the purpose of --deployment
[ci skip]
|
| | |
| | |
| | |
| | |
| | | |
The man page originally explained that `--deployment` is not appropriate for the `test` environment, which is misleading. In a CI environment, you *do* want to use `--deployment`, despite the fact that CI will likely be using `RAILS_ENV=test` when running tests.
This PR clarifies that `--deployment` is for production and CI, and avoids explicitly referencing Rails environment names.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Integrate Code of Covenant 1.1.0 changes
[ci skip]
|
|/ / /
| | |
| | | |
See also: http://contributor-covenant.org/version/1/1/0/code_of_conduct.md
|
|\ \ \
| | | |
| | | | |
Use `#!/usr/bin/env bash`
|
| | |/
| |/|
| | | |
bash may not always be located at `/bin/bash`.
|
|\ \ \
| |/ /
|/| | |
Fix typo
|
|/ / |
|
|\ \
| | |
| | |
| | | |
Version 1.10.4
|
| | | |
|
| | | |
|
| |\ \
| | | |
| | | | |
Implicit lock preservation
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When either `bundle check` is run, or any application requires the
`bundler/setup` file, Bundler will automatically check whether it is
possible to lock the Bundle. During the lock process, Bundler updates
the lock if the implicit locking changes the lock file.
Starting with the 1.10 release, Bundler includes a lockfile section
named BUNDLED WITH that includes the version of Bundler that generated
the lockfile. In order to minimize git churn, and guarantee that the
lockfile will only be changed when the user runs an explicit Bundler
command, Bundler will now only add or update the BUNDLED WITH section
during commands where the user asks for changes to the lock. This
includes, but is not limited to, `install`, `update`, `lock`, and
`package`.
Running the `check` command or loading an application that uses Bundler
will still now add or update the BUNDLED WITH section if, and only if,
the lockfile has also changed for a different reason (such as a gem
being updated).
Simply using an application, by running `bundle exec` commands or by
running `bin/rails` and the like, will not change the lockfile. As a
result, the intended workflow with the BUNDLED WITH section is now
slightly different than it was before:
1. When running `bundle install`, Bundler will update the version in
the lockfile if newer than the version present.
2. Then, check in the lockfile change, exactly as you would after
running install to change any other gem version.
3. Older versions of Bundler will not change the number in the lock,
but will warn the user that they are out of date.
refs bundler/bundler-features#80
refs #3697
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
we want to avoid changing the lock just to add BUNDLED WITH unless the
user is explicitly running a Bundler command; implicit locking should
not alter the lockfile.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The lazy-created UI is silent, and we need to be able to print for
things like ambiguous command error messages.
This reverts commit 849c649632b71111a06e71c0170ba966aca60d04.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | | |
fixes failing spec from 2a73e2d
|
| | | |
|
| | | |
|
| | |
| | |
| | | |
I couldn’t find it :P
|
| | |
| | |
| | |
| | | |
Since 9179412, `bundle i` is explicitly aliased and no longer ambiguous.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
we keep getting piles of notifications even when only a couple of jobs
fail, and the current theory is that it's a bug in fast_finish. let's
find out.
|
| | | |
|
| | |
| | |
| | | |
Some potential contributors go straight to DEVELOPMENT, and we want them to be able to use the list of useful contributions from CONTRIBUTING as well.
|
|\ \ \
| | | |
| | | | |
Improves the message displayed when cannot create config
|
| | | |
| | | |
| | | |
| | | | |
Add the `PermissionError` for file permission issues
|
|\ \ \ \
| | | | |
| | | | | |
Run ``` bundle check ``` with ``` disable_shared_gems ``` set to '1'
|
| | | | |
| | | | |
| | | | |
| | | | | |
--path option is specified
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Added optional remote argument for the rake release task
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | | |
Useful when working with multiple git remotes (origin/upstream/downstream).
`rake release[remote]` will push tags into the specified remote instead of the default one.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
missing period at end of README
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | | |
Add man docs for bundle install --force option
|
| | | | | |
|