What Is a Pipeline?

A Pipeline lets you define dependencies of jobs and create a path or a chain of builds. You can use pipelines to run continuous integration jobs.

To create a pipeline, you design a pipeline diagram where you define the dependencies of jobs. When you create a dependency of a job over another, you define the order of automatic builds of the dependent jobs. If required, the dependent jobs can be configured to use artifacts of the parent job too.

Note:

YAML pipelines are created in a .yml file that's stored in any of the project's Git repositories. You can view a YAML pipeline diagram layout, but you can't configure a YAML pipeline in the pipeline designer. See Configure Jobs and Pipelines with YAML.

In this diagram, Job 2 depends on Job 1 and runs after Job 1 is successful.

Description of the illustration odcs_build_pipeline_1.png

In this diagram, Job 2, Job 3, and Job 4 depend on Job 1 and run after Job 1 is successful. Job 2, Job 3, and Job 4 are scheduled in parallel. They can all run at the same time.

Description of the illustration odcs_build_pipeline_2.png

This diagram shows a complex example.

Description of the illustration odcs_build_pipeline_3.png

The above diagram defines these dependencies:

• Job 2 and Job 3 depend on Job 1 and run after Job 1 is successful

• Job 4 and Job 5 depend on Job 2 and run after Job 2 is successful

• Job 6 and Job 7 depend on Job 4 and run after Job 4 is successful

• Job 8 depends on Job 6 and Job 7 and runs after Job 6 and Job 7 are successful

• Job 1 is the initial job. Running it triggers a chain. All jobs after it in the chain (Job 2 through Job 8) run automatically, one after the other.

You can create multiple pipeline diagrams of jobs. If multiple pipelines have some common jobs, then multiple builds run some of those jobs. For example, in this figure, Pipeline 1 and Pipeline 2 have common jobs:

Description of the illustration odcs_build_multi-pipeline_new.png

Let’s assume that Pipeline 1 is defined first and Pipeline 2 is defined second. If both pipelines are triggered, the builds run in this order:

1. A build of Job 1 runs.

2. Builds of Job 2 and Job 3 of Pipeline 1 get in the build executor queue after Job 1 is successful. A build of Job 2 of Pipeline 2 also gets in the build executor queue after Job 1 is successful.

3. Builds of jobs in build executor queue run on first-come first-served basis. So, Job 2 and Job 3 of Pipeline 1 run first. Let’s call the build as Build 1 of Job 2 and Job 3. Then, another build of Job 2 of Pipeline 2 runs. Let’s call it Build 2 of Job 2.

4. A build of Job 4 of Pipeline 1 joins the build executor queue as soon as Job 2 is successful. A build of Job 3 of Pipeline 2 also joins the queue when Job 2 is successful.

5. As soon as the build executor is available, Build 1 of Job 4 runs and Build 2 of Job 3 also runs. Remember that Build 1 of Job 3 ran in Pipeline 1.

6. After a build of Job 3 of Pipeline 2 is successful, a build of Job 4 of Pipeline 2 joins the queue and runs when the build executor is available. Remember that this is Build 2 of Job 4 as Build 1 ran in Pipeline 1.

While creating multiple pipeline diagrams with common jobs, be careful if a job is dependent on artifacts of the parent job.