by just randomizing test order.
The original motivation to shard --jit-wait tests was forcing to test
major parts of code without actually stopping to test MJIT after
TracePoint enablement. But it tends to increase the test time because we
often compile the same thing in different shards.
I made this decision because we seem to hit 1.5h timeout of Wercker
these days, and Wercker is really bad at handling timeout (it does not
report timeout as failure, but just keeps it "pending" state)
https://app.wercker.com/ruby/ruby/runs/mjit-test2/5c78f15cc9e725000805b86c?step=5c79031d6c1e2c0008ac41c3
By randomizing this, we could test things randomly. The downside of this
approach is that we may not be able to find a specific commit that
caused a future failure by having TracePoint in a very early phase.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67158 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
from excludes directory names. test-mjit-wait / test-mjit are combined
and distributed as mjit-test1 and mjit-test2 now.
So the subdirectory names are changed to option names, --jit and --jit-wait.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65766 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Failure seems no longer reproductive recently...
Also I wrote a comment about this complicated test matrix and improved
parallelism a little more again.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65494 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
because the name "-wait" is no longer distinguishing these pipelines
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65483 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Currently TracePoint enablement may cancel all JITs. So for now,
separating test executions would reveal more failures.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65478 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I don't think we fixed that, but if so, I would like to see more test
failures. Previous failures didn't keep enough C-backtrace information
about the failure and it's hard to debug for now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65441 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
As Wercker is managing workflow by GUI, the commit had no impact for
behavior... I already fixed the workflow on GUI. Let revert that to
change it back to natural order.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65354 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
TestParallel in test/testunit/... seems to be slow. Let's see if this
contributes to loosen timeout or not.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65347 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
only on --jit CI. This test doesn't work on AppVeyor mswin either.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65340 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
since it actually doesn't contribute to CI build time so much, rather it
seems making it worse.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65335 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
at ruby repository. I also added a woraround to loosen timeout for
test-all. I resolved the issue that lets --jit-wait CI timeout, so this
workaround is not strictly needed, but this might make it easier to
debug when things go wrong.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65325 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
As the Wercker integration is already enabled, I added wercker.yml but
it's not working due to migration to this repository and I don't have
enough time to fix it immediately. I'll make it work in this evening.
Let me show green status on GitHub commit logs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65314 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
New. This was formerly https://github.com/k0kubun/mjit-test.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65313 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
k0kubun