By default, any failed step in a Codefresh pipeline will fail the whole pipeline.There are ways to change this behavior(the`fail_fast`property is explained later in this page), but specifically for parallel steps you can define exactly when the whole step succeeds or fails.

By default, any failed step in a Codefresh pipeline will fail the whole pipeline.You can change the default execution behaviorthroughthe`fail_fast`field, but specifically for parallel steps you can define exactly when the whole step succeeds or fails.

You can define steps that will be used to decide if a parallel step succeeds with this syntax:

Notice that, as with the`scale` syntax, the defined values/properties are merged between parent step (`MyUnitTests` in the example above) and children steps. For example, if you set an environment variable on the parent and also on child matrix steps , the result will a merged environment where all values are available.

If you use parallel execution mode for pipelines, you_cannot_ use_implicit parallel steps_.

To activate advanced parallel mode for the whole pipeline, you need to declare it explicitly at the root of the`codefresh.yml` file:

If you run the pipeline you will see that Codefresh automatically understands that`MyIntegrationTests` and`MyCleanupPhase` can run in parallel right after the unit tests finish.

Also notice the`fail_fast: false` line in the unit tests. By default, if*any* steps fails in a pipeline the whole pipeline is marked as a failure. With the`fail_fast` directive we can allow the pipeline to continue so that other steps that depend on the failed step can still run even.

Also notice the`fail_fast: false` line in the unit tests.

By default, if*any* step fails in a pipeline, the whole pipeline is marked as a failure. With`fail_fast` set to`false` as in the example, we can allow the pipeline to continue and complete execution.

It is important to understand the capabilities offered by Codefresh when it comes to error handling. You have several optionsin different levels of granularity to select what constitutes a failure and what not.

It is important to understand the capabilities offered by Codefresh when it comes to error handling. You have several optionsat different levels of granularity to select what constitutes a failure and what not.

By default,*any* failed step in a pipeline will abort the whole pipeline and mark it as failure.

You can use the directive`fail_fast: false`:

* In a specific step to mark it as ignored if it fails

**`fail_fast` with`strict_fail_fast`**

You can use the f`lag`fail_fast: false`:

* In a specific step to ignore it if it fails and continue execution

* At the root level of the pipeline if you want to apply it to all steps

Therefore, if you want your pipeline to keep running to completion regardless of errors the following syntax is possible:

If a parallel step has`fail_fast: false` in its definition, adding`strict_fail_fast: true` does not change the Build status returned even if a child step fails. This is because the parallel step itself is considered successful regardless of errors in child steps.

Therefore, if you want your pipeline to keep running to completion regardless of errors, you can add the following:

|`description`| A basic, free-text description of the step.| Optional|

|`timeout`| Defines an automatic approval/rejection if a specified amount of time has passed. The`duration` field is hours. By default it is set to 168 (i.e, 7 days). The`finalState` field defines what will happen after the duration time has elapsed. Possible values are`approved`/`denied`/`terminated`| Optional|

|`timeUnit` | This field defines possible options of`minutes`, or`hours`. If the field is not set, the default is`hours` | Optional

|`fail_fast`| If set to false, the pipeline will continue even when the step is rejected| Optional|

|`fail_fast`| Determines pipeline execution behavior in case of step failure. {::nomarkdown}<ul><li><codeclass="highlighter-rouge">true</code>: The default, terminates pipeline execution upon step failure. The Build status returns`Failed to execute`.</li><li><codeclass="highlighter-rouge">false</code>: Continues pipeline execution upon step failure. The Build status returns <codeclass="highlighter-rouge">Build completed successfully</code>. <br>To change the Build status, set <codeclass="highlighter-rouge">strict_fail_fast</code> to <codeclass="highlighter-rouge">true</code>.</li></ul>{:/}| Optional|

|`strict_fail_fast`| Specifies how to report the Build status`fail_fast` is set to`false`. {::nomarkdown}<ul><li><codeclass="highlighter-rouge">true</code>: Returns a Build status of failed on step failure.</li> <li><codeclass="highlighter-rouge">false</code>: Returns a Build status of successful regardless of step failures.</li></ul>{:/}**NOTE**: <codeclass="highlighter-rouge">strict_fail_fast</code> does not impact the Build status reported for parallel steps with <codeclass="highlighter-rouge">fail_fast</code> enabled. Even if a child step fails, the parallel step itself is considered successful. See also[Handling error conditions in a pipeline]({{site.baseurl}}/docs/pipelines/advanced-workflows/#handling-error-conditions-in-a-pipeline).| Optional|

|`stage`| Parent group of this step. See[using stages]({{site.baseurl}}/docs/pipelines/stages/) for more information.| Optional|

|`when`| Define a set of conditions that need to be satisfied in order to execute this step. You can find more information in the[conditional execution of steps]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) article.| Optional|

is scheduled in the same node once the pipeline resumes. Otherwise the volume will not be reused.

By default if you reject a pipeline, it will stop right away and it will be marked as failed. All subsequent steps after the approval one will not run at all.

By default if you reject a pipeline, it will stop right away and it will be marked as failed. All subsequent steps after the`approval` one will not run at all.

You might want to continue running the pipeline even whenit is rejectedby adding the`fail_fast` property in the approval step:

You might want to continue running the pipeline even whenone of the steps fail executionby adding the`fail_fast` property in the`approval` step. In this case, you can also add the`strict-fail_fast` flag to specify if the build status at the end of execution should return failed instead of successful which is the default.

{% highlight yaml %}

steps:

waitForInputBeforeProduction:

fail_fast: false

strict_fail_fast: true

type: pending-approval

title: Deploy to Production?

{% endraw %}

{% endhighlight %}

In this case you can also read the approval result and make the pipeline work differently according to each choice (demonstrated in the following section).

You can also read the approval result and make the pipeline work differently according to each choice (demonstrated in the following section).

{% endraw %}

{% endhighlight %}

In this example the second step thatis destroying an environment will only run if the user

approves the first step. In case of rejection the second stepwill be skipped.

In this example, the second step thatdestroys an environment will only run if the user

approves the first step. In case of rejection the second stepis skipped.

You can follow the same pattern for running steps when an approval step was rejected.

Here is a full example with both cases.

Codefresh has the ability to limit the amount of running builds for a specific pipeline with several concurrency policies in the pipeline settings. You can choose if a buildthat is in apending approval statewill count against the concurrency limits or not.

Codefresh has the ability to limit the amount of running builds for a specific pipeline with several concurrency policies in the pipeline settings. You can choose if a build pending approval statecounts against the concurrency limits or not.

As an example let's say that the concurrency limit for a specific pipeline is set to 2. Currently there is one active/running build and a second build that is pending approval.

|`timeout` | The maximum duration permitted to complete step execution in seconds (`s`), minutes (`m`), or hours (`h`), after which to automatically terminate step execution. For example, `timeout:1.5h`. <br>The timeout supports integers and floating numbers, and can be set to a maximum of 2147483647ms (approximately 24.8 days). <br><br>If defined and set to either `0s/m/h` or `null`, the timeout is ignored and step execution is not terminated.<br>See [Add a timeout to terminate step execution](#add-a-timeout-to-terminate-step-execution). |Optional|

| `fail_fast` | Determines pipeline execution behavior in case of step failure. {::nomarkdown}<ul><li><code class="highlighter-rouge">true</code>:The default, terminates pipeline execution upon step failure. The Build status returns `Failed to execute`.</li><li><code class="highlighter-rouge">false</code>: Continues pipeline execution upon step failure. The Build status returns <code class="highlighter-rouge">Build completed successfully</code>. <br>To change the Build status, set <code class="highlighter-rouge">strict_fail_fast</code> to <code class="highlighter-rouge">true</code>.</li></ul>{:/}| Optional |

| `strict_fail_fast` | Specifies how to report the Build status `fail_fast` is set to `false`. {::nomarkdown}<ul><li><code class="highlighter-rouge">true</code>:Returns a Build status of failed on step failure.</li> <li><code class="highlighter-rouge">false</code>: Returns a Build status of successful regardless of step failures.</li></ul>{:/}**NOTE**: <code class="highlighter-rouge">strict_fail_fast</code> does not impact the Build status reported for parallel steps with <code class="highlighter-rouge">fail_fast</code> enabled. Even if a child step fails, the parallel step itself is considered successful. See also [Handling error conditions in a pipeline]({{site.baseurl}}/docs/pipelines/advanced-workflows/#handling-error-conditions-in-a-pipeline).| Optional |

tag_policy:original

timeout:45m

fail_fast:false

strict_fail_fast:true

metadata:

set:

-qa:pending