TL;DR: Today we are changing our project setting called “Build Processing” to “Pipelines.” If you want to know why, read on. If not, nothing about this will affect you for a while, so you can stop here.

The change to “pipelines” begins our process of moving all projects over to having this setting on by default. This is the first of several changes we’ll be making to roll out the concept of pipelines throughout our platform. The vast majority of users should not notice any change because of today’s update, but we wanted to share more detail on what we are doing, and why, so you have more context on things that will be coming in the future.

What is a pipeline?

Pipelines are our name for the full set of configuration you run when you trigger work on your projects in CircleCI. Pipelines contain your workflows, which coordinate jobs.

What are the implications of pipelines?

With pipelines, all jobs run in a workflow, even if you don’t specify one in your configuration.

In the future, we will be adding a new pipeline-level parameters clause in config.yml, referenced in the pipeline scope. We will also be launching a new version of our API that has the ability to trigger pipelines with parameters and retrieve them and their workflows. Finally, we are working on a new UI that will unify the experience of viewing your pipelines and their jobs coordinated in workflows.

What does this change for me? How do I turn on pipelines?

Whatever you are running today should continue working without any intervention. We have some features (such as 2.1 configuration and orbs) that do require turning on pipelines, and in some rare cases we’ve seen users need to make tweaks to configuration when doing so.

Many of our customers are already using an early version of pipelines, even before we exposed them through our API and web UI. If you’ve used the latest features in our version 2.1 configuration and/or orbs, then you already have pipelines on for your project. Also, all projects added after September 1, 2018 already have pipelines enabled by default. If your project doesn’t yet have pipelines on you can find it under “Advanced Settings” in your project’s settings page. If you don’t see that option on your project’s settings page it means your project already has pipelines enabled.

Is a pipeline the same thing as a build?

Colloquially, we have often referred to this as “builds”, but that word proved problematic for two primary reasons. First, since the early days of CircleCI we’ve used the word “build” as what we now call a “job”, so it would be too ambiguous to refer to pipelines as “builds”. In June of 2018 (9 months ago), CircleCI updated our UI to change “Builds” to “Jobs” to help solve this issue, but we still have the word “build” in our API and environment variables as a synonym for “job” and don’t want to create any ambiguity.

More importantly, we’ve found that more teams are using CircleCI for a much broader array of automated processes than the word “build” implies. “Pipelines” more accurately reflect the broad applications of our platform. We think “pipelines” are also metaphorically appropriate for the set of stages we perform in processing your automation instructions against changes in your code.

Will I have to use pipelines?

The short answer is “no”, but we are working to turn on pipelines for all projects over the next several months. Pipelines will allow us to provide more powerful configuration and automation, as well as better optimization of your resources and more reliable performance. Our goal is for the transition to pipelines to occur without disrupting your existing workflows. If we identify outlier projects that would be disrupted, we’ll be reaching out to you, but for almost all users there should be no discernible impact. We are acutely aware that if something we change impacts your team there’s no solace in knowing that you were our outlier. We are dedicated to minimizing the impact any change we make can have on your teams.