-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test downstream users (JRuby to start with) of Truffle #101
Conversation
Example passing log https://s3.amazonaws.com/archive.travis-ci.org/jobs/113954147/log.txt |
I think this makes sense to try. If we get problems getting changes in because of these tests, but not caused by a Truffle problem, we can consider disabling this again. |
Test downstream users (JRuby to start with) of Truffle
You should never get problems integrating changes as the configuration means you can still push if it fails. It's just informational. |
I would prefer if downstream projects "listen on" pull requests for Truffle and run the tests themselves and then annotated the PR with their results. It would scale better. On the other hand I understand that it is harder to implement such system from an infrastructure point of view. This is good start. |
…/truffle:JavaInteropDebug to master Debugging via Truffle interop works as tested by SLDirectDebugTest * commit '47c3bfde4cb184fccf3ca93c885477a98eac27f5': Prevent objects from one PolyglotEngine to migrate to a different one Verify the objects passed back to the engine keep their identity Don't use the JavaFunctionObject in the AOT mode Test rewritten to use DebuggingSession. Verifies that debugging works when invoked via asJavaFunction Always wrapping TruffleObject to keep reference to associated polyglot engine, unless they are known to not need it (they are coming from Java interop) Debug test invoked via JavaInterop
This adds a new command
mx testdownstream
and runs that on Travis as an allowed-failure (it doesn't fail the overall commit if it fails, but you still see the result). Only JRuby so far, and runs 64k of JRuby's fastest tests so it only takes a couple of minutes.This allows you to see if your changes are immediately compatible with JRuby. For example it would have caught the problems with the
iterateFrames
changes.Potential problems are if the JRuby build is broken anyway (it very rarely is, but sometimes), or if people ignore it because it's allowed-failure.
@mickjordan am I using mx correctly here?