Skip to content
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

WIP: perf(.travis.yml): merge travis builds to fall under 5 builds #2782

Merged
merged 23 commits into from
Dec 3, 2018

Conversation

nharrand
Copy link
Collaborator

@nharrand nharrand commented Nov 26, 2018

As travis builds are limited to 5 parallel builds for Spoon, I propose to merge the 3 fastest builds into one. (This 3 builds are just verification that are not tests, and are quite fast.) Hopefully this new build is still faster than the slowest one, so it should be a net gain on both time and resources.

@nharrand nharrand changed the title perf(.travis.yml): merge travis builds to fall under 5 builds WIP perf(.travis.yml): merge travis builds to fall under 5 builds Nov 26, 2018
@nharrand
Copy link
Collaborator Author

Ok, my bad travis-coverage.sh is actually comparably slow to travis-jdk8.sh.

  • Would it make sense to make it failable and remove travis-jdk8.sh?
  • Or maybe can we merge former travis-verify.sh, and former travis-maven339-jdk8.shwithtravis-spoon-decompiler.sh` as they are the actual 3 fastest?

@surli
Copy link
Collaborator

surli commented Nov 26, 2018

I would personnally merge mvn339-jdk8 and jkd8 to keep only one. And I'd remove jdk9 since it won't be a LTS: we should only test against JDK8 and 11, since 11 is the new LTS. For corner cases we should have checks for 7, 9 and 10 on another CI.

@nharrand
Copy link
Collaborator Author

Sounds good to me.

Following your advice, I've replaced travis-jdk9.sh by travis-jdk11.sh and removed travis-jdk8.sh in favor of travis-maven339-jdk8.sh.

As we are still one build short, I've left the merge between travis-verify.sh and travis-spoon-decompiler.sh. (Alternatively, we can unmerge them, and remove travis-jdk10.sh)

@surli
Copy link
Collaborator

surli commented Nov 27, 2018

back to jdk9 while #1467 occurs with jdk11

Actually that's interesting: I'd be more in favor of keeping jdk11 and fixing quickly #1467. As I said JDK11 is supposed to be the new LTS for Java. We need to fix that ASAP.

@nharrand nharrand changed the title WIP perf(.travis.yml): merge travis builds to fall under 5 builds perf(.travis.yml): merge travis builds to fall under 5 builds Nov 27, 2018
@monperrus
Copy link
Collaborator

LGTM

@monperrus
Copy link
Collaborator

Waiting for #2789 to be merged before rebasing.

@monperrus monperrus changed the title perf(.travis.yml): merge travis builds to fall under 5 builds WIP: perf(.travis.yml): merge travis builds to fall under 5 builds Nov 28, 2018
surli pushed a commit that referenced this pull request Dec 3, 2018
…ges (#2789)

Related to adding a travis build with jdk 11 See #2782 

`CtFieldWrite.getTarget()` on `array.length` used to return a `CtVariableWrite` for some reasons... But with jdk 11 now returns  a `CtVariableRead`...

`FieldAccessTest#testFieldAccessOnUnknownType()` has been changed to handle both... by expecting a `CtVariableAccess`.

This (combined with #2787) fixes tests for jdk 11 as can be seen here ( https://travis-ci.org/INRIA/spoon/jobs/460289160 ).
Wether this is satisfaying or not, is up to debate. WDYT?
@nharrand
Copy link
Collaborator Author

nharrand commented Dec 3, 2018

OK, this finally works.
Ready for review.

@monperrus monperrus merged commit 6aa4064 into INRIA:master Dec 3, 2018
surli pushed a commit that referenced this pull request Dec 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants