Newcomer question: what are builds, jobs and stages?

What I am confused of are build and stage. ? I find the stage in some file, but I can not understand what is the build? From the description, I can not figure it out.

Using Travis CI - Test and Deploy with Confidence as an example:

  • A build is what the entire main panel of that page represents
  • Jobs are individual lines in the list under “build jobs”
  • Stages are groups of jobs that would run only after the previous stage completes. In that build, there are two stages – “test” (the default stage) and “ship it to quay.io”, run in that order.
    • Stages are optional. By default, all jobs run in parallel, subject only to Travis-imposed resource limits (from my experience, 3-5 Linux jobs and 2-3 OSX jobs from the same build run at a time).
    • In that build, the stage mechanic ensures that the “ship” job would only run after all 3 test jobs complete (and if any of them fails, it wouldn’t run at all).

Stages are a bit clunky because they are a late addition to the system and were stamped on top of existing mechanics.

In particular, matrix expansion knows nothing about stages and only adds jobs to the default stage (and the stages: clause is not considered an axis unlike most other top-level clauses). Any jobs that would go into other stages have to be specified manually one by one, via matrix: include:.


(Obsolescence note: the following information is no longer complete since the addition of workspaces)

Earlier stages can pass their resulting artifacts to later stages via Travis cache, but only in a very limited fashion: jobs from different stages have to have exactly the same configuration (except the stage name and scripts) – then they will share the same cache location.

  • In the example, the “ship” job with a blank env: will share a cache with an explicitly added “test” job with a blank env:. If you check their logs, you will see that the “test” job saves its results to the Travis cache and the “ship” job restores the same cache.
2 Likes