Today we made a small change to the navigation inside CircleCI. Where you saw the word “builds” you will now generally see the word “jobs”. This change has zero impact on the functionality of CircleCI; all your projects should behave identically to yesterday.


That’s all you need to know to enable you to keep using CircleCI just as before. If you’re curious about why we’ve made this change, read on.

Why did we do this?

This is the first of a series of changes to set the stage for the future of the CircleCI platform. Until today, the word “build” has been associated in our UI with both CircleCI 1.0 builds and CircleCI 2.0 jobs. With 1.0 coming to its end of life, we are taking the opportunity to clarify the distinction between jobs and builds. We decided to make this change in the UI now to minimize confusion later when we reintroduce the Builds page under the new hierarchy.

How did we get here?

When we introduced Workflows that could run multiple jobs, our Builds page listed all the jobs that were executing in the system. Since you can now execute many jobs in a workflow OR choose to execute a single job when you trigger a build, the meaning of “build” became divided into two things. The first case occurs when a particular run of your configuration is triggered by pushing against a branch to GitHub or Bitbucket. The second case occurs with the execution of a single job in that configuration. In CircleCI 1.0 those two concepts were the same thing. However, in CircleCI 2.0, if you define a single job called “build” they still feel like they are the same thing. When a workflow with many jobs is run, you end up with a bit of conceptual dissonance: a build can contain a workflow that executes jobs, and until today, we’ve been referring to those jobs within the workflow as “builds.” The change we made today is one solution to clear up that confusion.

Coming soon: builds, workflows, and jobs in a clear hierarchy

Until today, our UI reflected a two-level hierarchy in which workflows could contain jobs, but we called those jobs “builds.” What has become increasingly clear is that there are three levels: builds contain workflows, which contain jobs.


The concept of “builds” will be coming back later this year to signify each full run of your project configuration in a branch or tag. In other words, the Builds list will be a set of all the triggering events on your project. Each will represent a run of your configuration against your organization’s resources. In the new UI, this three-level hierarchy of execution in which a build is the “work order” to run a configuration, and that configuration can declare workflows that then invoke your jobs.

The new Builds page is still under design, but we wanted to give everyone reading this a preview of what’s to come, so here’s a sample mockup we’re working from (note: these are part of a larger design project and are subject to substantial change before launch).

New Builds Page.png