Build Stages lets you group jobs to run sequentially. Jobs within a stage run in parallel and subsequent stages run after the prior ones compete. You can also setup conditional stages, so some stages only run if certain logical conditions pass.
Stages has been a long time coming and we love how much it’s grown. What do you think about Build Stages? How do you use it (or not)? What would you like to see in future versions of Stages?
Are there plans to address the non-deterministic builds between jobs/stages on PR builds?
We are leaning heavily on stages however this issue is causing more and more frequent issues with the code base being out of sync with artifacts built in previous stages: https://github.com/travis-ci/travis-ci/issues/5882 .
Hey @ProTip! Sorry for the silence on the issue and here - I’m checking into timing and will let you know. In the meantime, autocancellation might help? It’ll cancel jobs that have not run yet, if a new job is created.
Thanks @acnagy . Auto cancel is a great feature, however this is in reference to https://github.com/travis-ci/travis-ci/issues/5882 . Commits to master during a PR build will change the checked out code between stages/jobs.
Ahh… right - got it, thanks for clarifying! Yeah, I went back to researching and we realized it’s definitely a non-trivial change, but one that’s probably doable… I’m scoping it out now, and will update here when I have news!
Stage priorities, so that builds could go like this: Master branch unit tests -> JDK7 branch unit tests -> master branch long tests -> JDK7 branch long tests.
Interesting! Noted! Related: Have you tried Conditions v1 for ways to make stages dependent on each other? If so, any chance you mind sharing why they didn’t work… super interested in that piece.
Because I’m talking about putting jobs from one build ahead of jobs from another build (against different branches; I have one master branch for Android and one for JDK8).
Ahhh… got it - that makes sense. Yeah, you could split up different tests of different JDKs into different stages, but yeah, they will be all for the same branch. It’s a really interesting case though about testing multiple branches in the same build – definitely think about that, and share the idea with the team. Thank you!
I’m not talking about combining both builds, just changing the way their jobs are scheduled so that when both are pushed, and master is pushed first, it’s:
master unit tests -> JDK7 unit tests -> master long tests -> JDK7 long tests
The stage priorities would just override the first-come-first-served rule that currently puts the master long tests before the JDK7 unit tests.
Make a previous stage the able to make artifacts for multiple jobs in the next stage: Allow a next-stage job read-only access to the cache of a previous-stage one; or make exported/imported artifacts .
The specific scenario I have in mind is to make a source package, then build it in various environments into binary packages to both make the binary packages and test that the source package can be built according to build instructions.
We’re hitting this problem on the AMP project.
While digging through the logs, I noticed that Travis jobs in multiple stages appear to be using the same merge commit (and same commit log) even though origin/master has moved forward. (I think this is what others are saying too.)
For details, see the comment at https://github.com/ampproject/amphtml/issues/21527#issuecomment-496717388
@acnagy, would it be possible to expose the commit SHA of origin/master at the start of the first stage of a Travis build via an environment variable, so that it can be used by subsequent stages to establish which files have changed by a pull request? I think this will serve as an acceptable workaround for us, instead of relying on the real origin/master, which is a moving target.
@rsimha Please open a new topic on this so as not to derail this one and make sure to include links to the builds showcasing the problem (links in the old Travis Github issue are stale).
Done. Posted a new topic at Origin/master moving forward between build stages.