Dec 19, 2023 · Dec 7, 2023 · Dec 10, 2023 · Dec 10, 2023 · Dec 10, 2023
diff --git a/_docs/pipelines/advanced-workflows.md b/_docs/pipelines/advanced-workflows.md

 ### Defining success criteria for a parallel step

 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.

 ## Parallel pipeline execution
 > If you use parallel execution mode for pipelines, you _cannot_ use _implicit parallel steps_.
 >**NOTE**:
 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.


 ### Multiple step dependencies

 ## Handling error conditions in a pipeline

 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:

 ```
 version: '1.0'
diff --git a/_docs/pipelines/steps/approval.md b/_docs/pipelines/steps/approval.md
 | `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><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                  |
 | `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                  |

 >Notice also that you if you use the [Codefresh Runner]({{site.baseurl}}/docs/installation/behind-the-firewall/) and your [Runner]({{site.baseurl}}/docs/installation/codefresh-runner/) is set up with local volumes, then the volume will only be present if the dind pod
 is scheduled in the same node once the pipeline resumes. Otherwise the volume will not be reused.

 ## Controlling theRejection Behavior
 ## Controlling therejection behavior

 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.

 `codefresh.yml`
 {% 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).


 ## Getting the Approval Result
 {% 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.

 ## Define Concurrency Limits

 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.

diff --git a/_docs/pipelines/steps/build.md b/_docs/pipelines/steps/build.md
 | `build_arguments`   | The set of [Docker build arguments](https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables-build-arg){:target="\_blank"} to pass to the build process.   | Optional                  |
 | `target`  | The target stage at which to stop the build in a multistage build. | Optional                  |
 |`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`  | Define the build behavior on step failure. When set to `true`, the default, ff a step fails, the build is stopped as well. To continue the build on step failure, set to `false`. | Default     |
 | `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                  |
 | `when`       | The set of conditions that need to be satisfied in order to execute this step.<br>For more information, see [Conditional execution of steps]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) .   | Optional |
 | `metadata`   | Annotate the built image with [key-value metadata]({{site.baseurl}}/docs/pipelines/docker-image-metadata/).  | Optional   |
 | `on_success`, `on_fail` and `on_finish`    | Define operations to perform upon step completion using a set of predefined [Post-step operations]({{site.baseurl}}/docs/pipelines/post-step-operations/).      | Optional                  |
  tag_policy: original
  timeout: 45m
  fail_fast: false
  strict_fail_fast: true
  metadata:
    set:
      - qa: pending
Original file line number	Diff line number	Diff line change
Expand Up		@@ -231,7 +231,7 @@ Running different types of tests (unit/integration/load/acceptance) in parallel

		### Defining success criteria for a parallel step

		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:

Expand DownExpand Up		@@ -557,7 +557,8 @@ of matrix variations can quickly grow if you add too many dimensions.
		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.

		## Parallel pipeline execution
		> If you use parallel execution mode for pipelines, you _cannot_ use _implicit parallel steps_.
		>NOTE:
		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:

Expand DownExpand Up		@@ -695,7 +696,8 @@ steps:

		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.


		### Multiple step dependencies
Expand DownExpand Up		@@ -935,15 +937,19 @@ steps:

		## Handling error conditions in a pipeline

		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:

		```
		version: '1.0'
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -55,7 +55,8 @@ step_name:
		\| `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><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 \|
		\| `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 \|

Expand DownExpand Up		@@ -153,11 +154,11 @@ max-width="90%"
		>Notice also that you if you use the [Codefresh Runner]({{site.baseurl}}/docs/installation/behind-the-firewall/) and your [Runner]({{site.baseurl}}/docs/installation/codefresh-runner/) is set up with local volumes, then the volume will only be present if the dind pod
		is scheduled in the same node once the pipeline resumes. Otherwise the volume will not be reused.

		## Controlling theRejection Behavior
		## Controlling therejection behavior

		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.

		`codefresh.yml`
		{% highlight yaml %}
Expand All		@@ -166,12 +167,13 @@ version: '1.0'
		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).


		## Getting the Approval Result
Expand DownExpand Up		@@ -201,8 +203,8 @@ steps:
		{% 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.
Expand DownExpand Up		@@ -295,7 +297,7 @@ it, the other two steps will be ignored.

		## Define Concurrency Limits

		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.

Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -98,7 +98,8 @@ step_name:
		\| `build_arguments` \| The set of [Docker build arguments](https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables-build-arg){:target="\_blank"} to pass to the build process. \| Optional \|
		\| `target` \| The target stage at which to stop the build in a multistage build. \| Optional \|
		\|`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` \| Define the build behavior on step failure. When set to `true`, the default, ff a step fails, the build is stopped as well. To continue the build on step failure, set to `false`. \| Default \|
		\| `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 \|
		\| `when` \| The set of conditions that need to be satisfied in order to execute this step.<br>For more information, see [Conditional execution of steps]({{site.baseurl}}/docs/pipelines/conditional-execution-of-steps/) . \| Optional \|
		\| `metadata` \| Annotate the built image with [key-value metadata]({{site.baseurl}}/docs/pipelines/docker-image-metadata/). \| Optional \|
		\| `on_success`, `on_fail` and `on_finish` \| Define operations to perform upon step completion using a set of predefined [Post-step operations]({{site.baseurl}}/docs/pipelines/post-step-operations/). \| Optional \|
Expand DownExpand Up		@@ -150,6 +151,7 @@ step_name:
		tag_policy: original
		timeout: 45m
		fail_fast: false
		strict_fail_fast: true
		metadata:
		set:
		- qa: pending
Expand Down