scala pr validation publishes sbt, saves 50 min on retry#71
scala pr validation publishes sbt, saves 50 min on retry#71adriaanm wants to merge 1 commit intoscala-ide:masterfrom
Conversation
Because of flakiness in the test suite, we often have to retry the job, which takes 50 minutes more than it should (that's how long it takes to build sbt, which never fails, and thus the retry could reuse earlier published result).
|
Review by @skyluc, please. |
|
Refer to this link for build results (access rights to CI server needed): https://jenkins.scala-ide.org:8496/jenkins/job/ghprb-uber-build-validator/108/ |
|
PS: The publishing part will need to be reworked when we can't publish to private-repo anymore /cc @jsuereth. I would love for the sbt step to be factored out, while we're at it. |
|
ping @skyluc |
|
/cc @mpociecha (in case this is relevant for you) |
|
I don't think I have anything in common with:
and
Edit: Or didn't you mean failed build? |
|
I meant reviewing this PR, which turns on publishing for sbt for integration of the IDE during Scala PR validation. This would save us 50 min on the retry when tests are flaky. Based on your comment on S |
|
Pardon me. I was only looking at tests which use Thread.sleep (yes, the ugly thing) - how to get rid of this/rewrite them to be resistant to slowdowns on Jenkins. Nothing more - especially related to the build configuration. That's why I misunderstood you. Anyway it's great if it really ensures that we'll rerun tests without building everything once again! 👍 Maybe it's not the best place to discuss this, but by the way: I'm not sure how often do you have such situations though. => Whether it makes sense to spend/waste some time preparing this. Obviously it's also a question how closely you and Scala IDE team cooperate. |
|
No worries at all, and thanks for the thorough explanation! I'm traveling this weekend through Monday, but maybe it makes sense to do a quick hangout next week to discuss? /cc @dragos |
|
I'm happy to merge this, but does it work? I think we need to setup a publish URL as well. What repository should it use for publishing? the scala-prs one? |
|
Regarding speed, where does PR validation run now? If it's no longer in Lausanne, where we had a proxy configured, a good way to speed up dbuild is to setup an artifactory close to where it runs. Out of those 50 min, actual compilation time is about 5, the rest is overhead :( |
|
Ah, I thought the publish URL was already set up for the other modes of operation. I'm not sure how it works behind the scenes. Validation runs in Lausanne, but maybe the slow down is because of an issue with the maven mirror on moxie? |
|
I'll give it a try and see what happens. I'm not sure either. |
|
Apologies for the confusion. I don't know why I thought the job was still running in Lausanne... I'll look into a minimal maven mirror hosted with the workers. |
|
(Tracked at: scala/scala-jenkins-infra#13) |
|
Subsumed by #73. |
Because of flakiness in the test suite, we often have to retry the job,
which takes 50 minutes more than it should (that's how long it takes
to build sbt, which never fails, and thus the retry could reuse earlier
published result).