We have a check on an `at_exit` hook that checks that system bundler is
never loaded instead of our development copy. The check was failing in
these cases, but in a silent way because the errors were being swallowed.
This commit changes these specs to make sure they load the right
bundler.
cd1c1bc297
On bundler 3, the `--deployment` flag doesn't exist, so the `bundle
install --deployment` command was failing silently and the spec was
verifying a different scenario.
Change the spec to work the same regardless of bundler's major version.
Also, from the spec description it was not apparently that a specific
case involving deployment mode was being tested, so I reworded it to
make it more apparent.
3e33e2b927
On bundler 3, where the default install path is `.bundle`, these specs
were trying to change permissions of the
`.bundle/ruby/<ruby_abi_version>` folder, which didn't exist yet,so the
permission changing command was failing and the spec was not testing the
right thing.
Change the specs so that the permissions are correctly changed, by first
configuring the local path to be `.bundle` (which creates the `.bundle`
folder), and then changing permissions of the `.bundle` folder
explicitly, which exists already.
2833162fb0
Bundler 3 installs by default to `.bundle`. That means that, because the
`bar` gem was not previously available at this location but as a system
gem, the initial `bundle install` was silently failing. As a
consequence, the spec was not testing the exact scenario it meant to
test.
202399521c
This spec is specifically testing for the case where there's no
`Gemfile.lock` file and it's only doing the expected thing because the
`bundle install` command is silently failing. Remove the `bundle
install` to reduce confusion.
ec39fbde0e
This command is failing because of the same reason that the subsequent
`bundle exec` is failing: the gemspec is invalid. The `bundle install`
here deviates the `bundle exec` focus from the test and is unnecessary:
all we need is a `Gemfile` that will trigger the `bundle exec`, so let's
create and avoid the extra command.
eb83cf6cf1
It turns out that this test is checking essentially nothing useful. The
paperclip gem doesn't exist in our setup, so initial install is failing
and the test is only checking that calling `bundle check` 3 times on a
broken setup always returns the same thing.
I went to the history of this test:
* 105654a31e
* ae53be1f87
* d19f4a7b32
* 092f169d01
* 36878435b5
And have finally decided to remove it since I'm not sure changing it to
something else will lead to testing something useful and not already
tested.
6184322967
This spec was broken. The second `bundle install` was silently failing.
This means that the spec was actually checking an scenario completely
different from the one that was supposed to be tested. And also a very
dummy one: that running `bundle cache` twice doesn't cache a completely
unrelated gem.
f11a5d2df9
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.
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.
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.
128b4596e1
33588714/job/hcgin7xo3sarr0r2
```
2) Failure:
WEBrick::TestFileHandler#test_cjk_in_path
[D:/a/ruby/ruby/src/test/webrick/utils.rb:72]:
exceptions on 1 threads:
U+3042 to WINDOWS-1252 in conversion from UTF-8 to WINDOWS-1252
```
http://ci.rvm.jp/logfiles/brlog.trunk-theap-asserts.20200618-002305
```
I, [2020-06-18T00:28:11.661066 #31625] INFO -- : 1) Failure:
I, [2020-06-18T00:28:11.661157 #31625] INFO -- : WEBrick::TestFileHandler#test_cjk_in_path [/tmp/ruby/v3/src/trunk-theap-asserts/test/webrick/utils.rb:72]:
I, [2020-06-18T00:28:11.661216 #31625] INFO -- : exceptions on 1 threads:
I, [2020-06-18T00:28:11.661269 #31625] INFO -- : U+3042 from UTF-8 to US-ASCII
```
to suppress the following failure:
20200617T130007Z.fail.html.gz
20200617T131443Z.fail.html.gz
```
1) Failure:
TestGemPackage#test_extract_symlink_parent_doesnt_delete_user_dir
[/export/home/chkbuild/chkbuild-gcc/tmp/build/20200617T130007Z/ruby/test/rubygems/test_gem_package.rb:620]:
--- expected
+++ actual
@@ -1 +1 @@
-"installing into parent path /export/home/chkbuild/chkbuild-gcc/tmp/build/20200617T130007Z/ruby/tmp/test_rubygems_15916/extract/user/dir of /export/home/chkbuild/chkbuild-gcc/tmp/build/20200617T130007Z/ruby/tmp/test_rubygems_15916/extract/subdir is not allowed"
+"installing into parent path link/dir of /export/home/chkbuild/chkbuild-gcc/tmp/build/20200617T130007Z/ruby/tmp/test_rubygems_15916/extract/subdir is not allowed"
```
These CI environments use very long TMPDIR for some reason.
The test case creates a directory in TMPDIR and attempts to add a
symbolic link to the path into a tarball. However, tar format limits
the maximum length up to 99, so the path is truncated.
This truncation makes the path check of `Gem::Package#install_location`
pass through, and then the check of `#mkdir_p_safe` raises an error.
The error message is slightly different from the expected value, so the
test fails.
I'm unsure what to do, so I tentatively skip the test when TMPDIR is
long. I'll create a ticket into rubygems bug tracker.
