| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The commands these specs run were throwing warnings in bundler 2, and
failing on bundler 3, effectively testing a different scenario to what
they were supposed to.
https://github.com/rubygems/rubygems/commit/97ac1ced49
|
|
|
|
|
|
|
|
|
| |
The `rails_fail` name is misleading because there's no specific reason
why such a gem would need to fail. As a matter of fact, `bundle
install`'ing a Genfile with only that dependency like the spec the
previous commit adds is not expected to fail.
https://github.com/rubygems/rubygems/commit/b947f40701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `only_update_to_newer_versions` feature flag will enable some new
behaviour in bundler 3 (or maybe earlier if we decide to consider it a
bug fix) that prevents `bundle update` from unexpectedly downgrading
direct dependencies.
This seems reasonable, but the current implementation is adding
additional requirements for all locked dependencies, not only from the
ones in the `Gemfile`. That causes some situations where the `Gemfile`
is edited and will resolve to older versions to start failing.
This commit fixes the problem by making sure extra requirements are
added exclusively for direct dependencies in the `Gemfile`, not for all
direct dependencies in the lock file.
https://github.com/rubygems/rubygems/commit/128b4596e1
|
|
|
|
|
|
|
|
|
| |
The `gem_command` helper was failing to require `support/hax.rb`, which
takes care of making sure rubygems actually picks up the right `ruby`
executable under ruby-core setup (`ENV["RUBY"]`). This caused binstubs
to be generated with a wrong shebang, and that caused `bundle exec` to
not work. The error message was pretty confusing though due to
https://bugs.ruby-lang.org/issues/16952.
|
|
|
|
| |
https://github.com/rubygems/rubygems/pull/3666/commits/ca5bf584026c9fd3a288eb10c65493e9f01ccc44
|
|
|
|
|
|
|
|
| |
Instead, use the non-deprecated option except when specifically testing
deprecated CLI flags. In that case, pass the flag directly and limit
the specs to `bundler < 3`.
https://github.com/rubygems/rubygems/commit/3d5e186241
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/f878a81f22
|
|
|
|
|
|
|
|
|
| |
Some of them were passing "by chance" because they used a `bundle
install` command that failed, but the assertion was using the result of
the previous. Others were skipped on bundler 3. Now they all pass in all
versions.
https://github.com/rubygems/rubygems/commit/cedf611e11
|
|
|
|
|
|
| |
Even if no explicit flags were passed to it.
https://github.com/rubygems/rubygems/commit/0598cbb68c
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/731b3783f1
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/6395392b83
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/3372b21553
|
|
|
|
|
|
|
|
|
| |
This spec was originally written many years ago to verity gems were
properly "remembered" in the lock file. At this point, the test feels a
bit dummy since the first `bundle install` already runs on a "clean
machine".
https://github.com/rubygems/rubygems/commit/dbfefb3f5a
|
|
|
|
|
|
| |
They seem to be passing?
https://github.com/rubygems/rubygems/commit/a00d1e6896
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Features:
- Add caller information to some deprecation messages to make them easier to fix [#7361](https://github.com/bundler/bundler/pull/7361)
- Reconcile `bundle cache` vs `bundle package` everywhere. Now in docs, CLI help and everywhere else `bundle cache` is the preferred version and `bundle package` remains as an alias [#7389](https://github.com/bundler/bundler/pull/7389)
- Display some basic `bundler` documentation together with ruby's RDoc based documentation [#7394](https://github.com/bundler/bundler/pull/7394)
Bugfixes:
- Fix typos deprecation message and upgrading docs [#7374](https://github.com/bundler/bundler/pull/7374)
- Deprecation warnings about `taint` usage on ruby 2.7 [#7385](https://github.com/bundler/bundler/pull/7385)
- Fix `--help` flag not correctly delegating to `man` when used with command aliases [#7388](https://github.com/bundler/bundler/pull/7388)
- `bundle add` should cache newly added gems if an application cache exists [#7393](https://github.com/bundler/bundler/pull/7393)
- Stop using an insecure folder as a "fallback home" when user home is not defined [#7416](https://github.com/bundler/bundler/pull/7416)
- Fix `bundler/inline` warning about `Bundler.root` redefinition [#7417](https://github.com/bundler/bundler/pull/7417)
|
|
|
|
|
|
| |
This reverts commit 3dc509e645abb497e4dc92a7c42be471ff87db0b.
https://github.com/bundler/bundler/commit/b5766564fb
|
|
|
|
|
|
| |
This reverts commit 00b095b98fe4bd44950beaf3bc9f1d91eac7b69e.
https://github.com/bundler/bundler/commit/e93bce3b20
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
|
|
|
|
|
|
|
| |
Instead, make sure we always load the local copy of bundler during
specs, and never end up using the default copy.
https://github.com/bundler/bundler/commit/ac655ffeda
|
|
|
|
|
|
|
|
| |
When Gemfile would specify path sources as relative paths starting with
"./", the lockfile would have inconsistent order on `bundle install` and
`bundle update`.
https://github.com/bundler/bundler/commit/c7532ced89
|
|
|
|
| |
https://github.com/bundler/bundler/commit/5978a88f33
|
|
|
|
|
|
|
| |
So that the behavior is the same regardless of the tested bundler
version.
https://github.com/bundler/bundler/commit/664549427a
|
|
|
|
| |
https://github.com/bundler/bundler/commit/4c6a3c3cf7
|
|
|
|
| |
https://github.com/bundler/bundler/commit/2a7a5daba0
|
|
|
|
| |
https://github.com/bundler/bundler/commit/b5900e57a4
|
|
|
|
| |
https://github.com/bundler/bundler/commit/2a44090cb6
|
|
|
|
| |
https://github.com/bundler/bundler/commit/00b095b98f
|
|
|
|
| |
https://github.com/bundler/bundler/commit/3dc509e645
|
|
|
|
| |
https://github.com/bundler/bundler/commit/785c7af1f3
|
|
|
|
| |
https://github.com/bundler/bundler/commit/5e08e849ec
|
|
|
|
| |
https://github.com/bundler/bundler/commit/e6a03f1102
|
|
|
|
| |
https://github.com/bundler/bundler/commit/5946d62ad0
|
|
|
|
| |
Pick from 8dd59e3ba97eb80a599f8149f31bf40773b69dc0
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67542 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67541 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
https://github.com/bundler/bundler/commit/a53709556b95a914e874b22ed2116a46b0528852
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67539 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66710 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
| |
We have the platform issue on heroku:
* https://gist.github.com/schneems/26452540f6e2bbbcf2ea144f45f6b305
* https://github.com/heroku/heroku-buildpack-ruby/issues/833
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66323 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65672 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
* It update bundler 2 mode to bundler 3.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65523 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
|
|
|
| |
* bin/*, lib/bundler/*, lib/bundler.rb, spec/bundler, man/*:
Merge from latest stable branch of bundler/bundler repository and
added workaround patches. I will backport them into upstream.
* common.mk, defs/gmake.mk: Added `test-bundler` task for test suite
of bundler.
* tool/sync_default_gems.rb: Added sync task for bundler.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65509 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|