How to pause pipelines for manual approval
approval step allows you to pause a pipeline and wait for human intervention before going on.
Some example scenarios for using the approval step:
- Pause before deploying to production
- Pause before destroying an environment
- Pause for some manual smoke tests or metric collection
||The free-text display name of the step.||Optional|
||A basic, free-text description of the step.||Optional|
||Defines an automatic approval/rejection if a specified amount of time has passed. The
||This field defines possible options of
||If set to false, the pipeline will continue even when the step is rejected||Optional|
||Parent group of this step. See using stages for more information.||Optional|
||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 article.||Optional|
Pausing the Pipeline
Once the pipeline reaches an approval step it will stop. At this point it does not consume any resources. In the Codefresh UI you will see the Approve/Reject buttons.
Once you click any of them the pipeline will continue. Further steps in the pipeline can be enabled/disabled according to the approval result.
By default, a pipeline that contains an approval step will pause for 7 days (168 hours) onces it reaches that step. If you want some automatic action to happen after a specified time period you can define it in advance with the
This pipeline will wait for approval for two hours. If somebody approves it, it will continue. If nothing happens after two hours the approval step will be automatically rejected.
By default, any Codefresh user can approve any pipeline that is paused at the approval state. If you want to restrict the approval action to a subset of people, you can use the access control capabilities that Codefresh provides.
This is a two-step process. First you need to tag your pipeline with one or more tags (tag names are arbitrary). You can edit tags in the pipeline settings screen.
Once you have tagged your pipelines you can create one or more access rules that restrict approval to specific teams within your organization.
Keeping the Shared Volume after approval
As soon as a pipeline starts waiting for an approval, all contents of the shared Codefresh volume are lost. Once the pipeline continues to run, all files that were created manually inside the volume are not available any more.
If you want to keep any temporary files that were there before the approval, you need to enable the respective policy in your pipeline settings.
You can either set this option per pipeline, or globally in your account in the Codefresh UI through Pipeline Settings.
Notice that if you do decide to keep the volume after an approval, the pipeline will still count as “running” against your pricing plan (if you use the SAAS version of Codefresh). If you don’t keep the volume, the pipeline is stopped/paused while it is waiting for approval and doesn’t count against your pricing plan. We advise you to keep the volume only for pipelines that really need this capability.
Notice also that you if you use the Codefresh Runner and your 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 the Rejection 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.
You might want to continue running the pipeline even when it is rejected by adding the
fail_fast property in the approval step:
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).
Getting the Approval Result
As also explained in step dependencies, all steps in the Codefresh pipeline belong to a global object called
steps (indexed by name). You can read the
result property for an approval step to see if it was approved or rejected.
Here is an example:
In this example the second step that is destroying an environment will only run if the user approves the first step. In case of rejection the second step will be skipped.
You can follow the same pattern for running steps when an approval step was rejected. Here is a full example with both cases.
Here is the pipeline state after a rejection:
Note that we have added the
fail_fastproperty in the approval step because we want the pipeline to continue even when the step is rejected.
You can see that only two steps were ignored. If you rerun the pipeline and approve 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 build that is in a pending approval state will count 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.
- If the pipeline settings define that builds in pending approval count against concurrency, then if you launch a third build it will wait until one of the first two has finished
- If the pipeline settings define that builds in pending approval do not count against concurrency, then if you launch a third build it will execute right away.
There isn’t a correct or wrong way to set this option. It depends on your organization and if your consider builds pending approval as “active” or not.
You can either set this option per pipeline, or globally for an in the Codefresh UI through Pipeline Settings.
If you also enable Slack integration in Codefresh you will have the choice of approving/rejecting a pipeline via a Slack channel
To enable this behavior, you need to activate it in the Slack settings page:
Also, if you run a pipeline manually that includes an approval step, you should select the Report notification of pipeline execution option as explained in Monitoring Pipelines.
Conditional execution of steps