Seems clang-7 has false-positives around memory sanitizer.
This line should not be reported because the memory region is
correctly unpoisoned beforehand:
https://travis-ci.org/ruby/ruby/jobs/524766381
Clang 8 seems to fix it.
After `GC.compact`, test/shell/test_command_processor.rb seems to be made
unstable on osx Travis like https://travis-ci.org/ruby/ruby/jobs/523487997.
For investigating whether it's impacting that or not, let me try isolating
that for osx Travis for now.
This reverts commit a1b5d20068.
Revert "Revert "Skip recompiling tests on i686 Linux""
This reverts commit 7b88a9207b.
Revert "Simplify matrix for debugging"
This reverts commit e85d6c5c5e.
Sorry, these 3 commits were under debugging in
https://github.com/ruby/ruby/pull/2129 but accidentally merged by using
`git svn dcommit` instead of `git push` to the topic branch 🙇
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67538 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Actually what has randomly failed was `make install`:
https://travis-ci.org/ruby/ruby/jobs/512988177
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67376 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to check if it resolves "Permission denied" problem.
https://travis-ci.org/ruby/ruby/jobs/507381339https://travis-ci.org/ruby/ruby/jobs/507392198
TBH I'm not exactly sure why it happens, but I don't have infinite time
to understand this. It would be appreciated to identify the root cause
and remove `DISABLE_CACHE` again if you're sure your patch fixes the problem.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67281 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
r66692's `export RUBYOPT="-w"` does not seem to work.
Passing `RUBYOPT="-w"` to `make test-all`'s argument works.
Let's try having this for all environments.
(see r66690 for motivation)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66698 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
actually current test-all does not fail with RUN_OPTS="-w".
and chkbuild seems to use RUBYOPT="-w"
bad4681c30/chkbuild/ruby.rb (L605)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66692 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
currently Travis and AppVeyor does not run tests with test-all,
but RubyCI uses -w and currently all RubyCIs are failing.
It might be better to fail at least one CI in Travis to notice it
earlier.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66690 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
With travis_wait, we may not need -j3 for test-all anymore, but still we
need to avoid hanging on building Ruby somehow.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66504 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Using -v somehow makes test-all on osx stable. Let me check if travis_wait
solves the issue or not.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66501 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Even building ruby seems to hang for unknown reasons.
https://travis-ci.org/ruby/ruby/jobs/471021727
Travis's osx environment is too fragile. Avoid anything dangerous.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66484 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
osx build has failed too often. we don't know why.
To know which test hangs forever, we might want to have hard timeout for
all test case (like 9min, slightly less than no-output timeout) in test-all.
But it's a little hard to implement and I would workaround an unknown
cause somehow.
It's known that -j is harmful for some tests in test-all. Let's try to
remove it first, and if it doesn't work, I'll resurrect -v option to
easily know which test is the culprit.
Slow correctness is much better than fast false-positive.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66482 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Before this changeset (since r58071) we did not download files
from unicode.org but just touch some files. This is a kind of
hack that people normally don't do at home.
We are caching other files between builds now. Why not also save
those files downloaded from elsewhere. This covers more
realistic workload, I guess.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66085 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
`[` is a meta character in YAML. `- [` starts an array,
so it should end with `]`; but it was not.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66084 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It was probably me, 7 years ago, in r33844, who started overly
quoting YAML strings. But now, this file grown up 50+ times from
6 lines to more than 300. It is more annoying than convenient to
quote everything to add backslashes here and there.
Just use quotes only when necessary.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66056 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
GCC_FLAGS is not an array and CC is finally passed to configure as
single string. Pass CC via the environment variable, so it does
not need to be quoted anymore.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66029 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Exclude OpenSSL because we don't plan to debug libssl,
also track origins of uninitialized bits.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65980 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* .travis.yml: use dedicated flags, cflags and others, not to
override optflags, warnflags and debugflags.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65799 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
When CFLAGS is passed on travis, warnflags seems not working.
Let's add them directly to prevent clang form messing up the logs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65796 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
OK, nobody is actively willing to maintain this configuration. Just
stop annoying people by build failures. See:
https://travis-ci.org/ruby/ruby/jobs/455377387
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65742 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Now that ccache is enabled. Compilations are made IO heavy, not CPU
bound. This means parallel jobs beyond CPU count could gain more
speed. From my experiment, I can conclude the good old "number of
cores plus one" tactics works the best.
The experiment: https://travis-ci.org/shyouhei/ruby/builds/454891855
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65741 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Urabe, Shyouhei
Kazuhiro NISHIYAMA
Takashi Kokubun
kazu
k0kubun
nobu
shyouhei
naruse