New Build Stages



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: .


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 . 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.