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:
https://rubyci.org/logs/rubyci.s3.amazonaws.com/solaris11-gcc/ruby-master/log/20200617T130007Z.fail.html.gzhttps://rubyci.org/logs/rubyci.s3.amazonaws.com/android29-x86_64/ruby-master/log/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.
Namely, those generated under `/tmp`.
The previous approach was brittle and broken in the case of ruby-core,
because under that setup, the current folder is in the original
`$LOAD_PATH`, and dummy features are created under `./tmp`, so they were
failing to be reset.
This was guaranteed by our gitignore setup where a `tmp/` folder is
always present right after cloning the repository, but was not
guaranteed under the ruby-core setup.
This alternative approach should always work.
This was added ~8 years to fix some json warning but I'm pretty sure
it's not needed anymore.
This has caused several issues in both ruby-core and rdoc test suite and
it doesn't make much sense to me these days so let's kill it.
If you look at the code flow (break -> goto), this assignment never
makes any sense. Should just remove.
I _guess_ this behaviour is unintended. Original code at commit
4dc1a21809 did something. It might be
the code flow that is buggy. However rubyspec already includes this
particular edge case at ruby/core/module/undef_method_spec.rb. I don't
think we can change the way it is any longer.
- Improve careless examples
- Insert `--` before a file name for cat(1)
- Insert `-e` before a search pattern for grep(1)
- Add a caution about passing an arbitrary argument to a command
Ensure that the argument is an Integer or implicitly convert to,
before dereferencing as a Bignum. Addressed a regression in
b99833baec.
Reported by u75615 at https://hackerone.com/reports/898614
In `ruby-head` (where system rubygems already has the `XDG` standard
implementation), some tests currently depend on the presence of a
`~/.gem` folder in the home of the user that runs the tests. If that
file is present, tests pass, otherwise they don't.
For example, the following passes if you have a `~/.gem` folder but
fails otherwise with:
```
$ rake TESTOPTS="--name=/TestGemCommandsGenerateIndexCommand#test_execute$\|TestGemCommandsUpdateCommand#test_execute_user_install/ -v"
Run options: "--name=/TestGemCommandsGenerateIndexCommand#test_execute$|TestGemCommandsUpdateCommand#test_execute_user_install/" -v --seed 17318
# Running:
TestGemCommandsGenerateIndexCommand#test_execute = 0.02 s = .
TestGemCommandsUpdateCommand#test_execute_user_install = /rubygems/test/rubygems/test_gem_commands_update_command.rb:412: warning: instance variable @user_install not initialized
0.04 s = F
Finished in 0.095337s, 20.9783 runs/s, 20.9783 assertions/s.
1) Failure:
TestGemCommandsUpdateCommand#test_execute_user_install [/rubygems/test/rubygems/test_gem_commands_update_command.rb:414]:
user_install must be set on the installer
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1)
Tasks: TOP => default => test
(See full trace by running task with --trace)
```
This is because the very initial `require` of the default `did_you_mean`
gem that ruby does on startup runs _before_ the global `setup` hook of
our tests run. During this require `Gem.data_home` and its value is
memoized to a path in the real users home (not the fake user's home that
our tests setup, since that code hasn't run yet). Then that memoized
value is used when looking for the default folders to look for gems, and
since there's no `~/.gem` folder, its value is actually used as part of
the `Gem.user_dir` folder in `Gem::Specification.dirs` (this is how
we've approached backwards compatibility for the `XDG` feature). That
means dummy test gems with the `--user-install` flag are installed to
global, real locations and everything is messed up.
This commit fixes the issue by resetting the `Gem.data_home` value in
case it has already been memoized.
... based on CRC32 of names of the test suites.
Formerly, `make test-all` randomized the order of the test suites by
using `Array#shuffle`. It also shows `--seed N` to reproduce the order,
but it was not reproducible when a suite set is different.
This change sorts the suites by CRC32 hash of the suite names with a
salt generated by the seed.
Yusuke Endoh
Nobuyoshi Nakada
git
Takashi Kokubun
David Rodríguez
Kazuhiro NISHIYAMA
卜部昌平
Koichi Sasada
Alan Wu
S.H
Akinori MUSHA
Josef Šimánek