Pipeline Skip Conditions

Updated 8 hours ago by Michael Katz

You can use skip conditions to fine-tune whether, and when, Pipeline stages will execute. This topic covers:

Before You Begin

Overview

Skip conditions enable you to disable the execution of individual Pipeline stages (such as Workflows). They also enable you to conditionally execute (or skip) stages based on factors evaluated when the Pipeline runs. You can use them in scenarios like these:

  • Set a stage to never execute. This is useful when you want to add new stages to a Pipeline’s structure, but prevent those stages from executing while they are still under development.

  • Set a stage to execute conditionally, based on the value assigned to a variable in an earlier stage of the same Pipeline.

Skip Execution

Use the Option to skip execution drop-down list to select the condition under which this Pipeline stage should execute:

The options available here are:

  • Do not skip – This is the default behavior. Harness will not override execution. The stage will simply execute— assuming that its preconditions within the Pipeline, if any, are met.

  • Skip always – The stage will never execute. With this option, you can maintain a stage within a Pipeline's structure, but disable it, either temporarily or indefinitely.

  • Skip based on assertion expression – This option is available in Execution Step stages (which run Workflows). It enables you to specify an expression that determines whether the stage should execute. See usage details below.

Skip Based on Assertion Expression

Use the Skip based on assertion expression option to conditionally skip a Pipeline stage. To enable this option, you can define a new variable in an Approval stage, as outlined below. (You can also work with any variable that was already defined, or passed in by a Trigger, in an earlier Pipeline stage.)

Next, in an Execution stage, you evaluate the variable in an expression, to determine whether to execute the stage. In the example outlined below, we'll define a variable in Stage 1, and then evaluate it in Stage 3:

In the above example, Stage 2 is grayed out (disalbed) because it has been set to Skip Always.

Here is how the variable traverses those two stages:

Create Input Variable

In an Approval stage within a Pipeline, you can define an input variable as follows:

  1. Click to open the Advanced Settings section.
  2. In the resulting Additional Input Variables section, click Add Variable.

  1. Give your new variable a Name and Default Value. You will later use the name to reference the variable in one or more Execution stages of the Pipeline. You will use the value in an expression to determine whether the Execution stage should execute.
  2. In Publish Variable Name, enter a parent name for the adjacent Additional Input Variables. The parent name helps to avoid conflicts when referencing variables of the same name within the same Pipeline.

    In this example, the parent name is set to releaseInfo, and the input variable's name is releaseTarget. So, in later Pipeline stages, you will reference this variable as releaseInfo.releaseTarget. Its default value is set as PROD.
  3. To add more input variables, click Add Variable. (All variables that you define in this stage will share the same parent name, prepended from the Publish Variable Name field.)
  4. Click Submit to save this stage, along with its variables. Now you can use these variables in assertion expressions within Execution stages, as described below.

Modify Value During Deployment

When you deploy this Pipeline, the Approval stage that we've just configured will show authorized approvers the dialog shown at right below. The releaseTarget variable appears with its Default Value of PROD. Approvers can change the value here before clicking Approve.

Evaluate Assertion Expression

Let's now examine the configuration of an Execution stage later in the same Pipeline. In the Option to skip execution drop-down, we've selected the condition: Skip based on assertion expression.

In the adjacent Assertion Expression field, we reference the releaseInfo.releaseTarget variable that we defined earlier in the Approval stage. We assert a value of QA:

When we first created this input variable, we set its value to PROD. During deployment, if we assume that this value has not been changed in any intermediate stage—remember that users or scripts can change a variable's value in an Approval stage—the assertion expression will be evaluated as false.

In this case, this Pipeline stage will not be skipped, because the skip condition (the assertion expression) has not been met. Therefore, Harness will attempt to execute the stage.

More About Assertion Expressions

The example above shows an assertion expression evaluating an input variable that we created specifically for this purpose, earlier in the same Pipeline. However, assertion expressions can also reference any variable published in any previous stage of the Pipeline.

The Assertion Expression field allows you to test using multiple operators, not just equality. For example, ${release.test} > 1 would also be a valid Assertion Expression entry.


How did we do?