Jenkins Tutorial – Part 4 – Post Actions

In this part of the Jenkins tutorial, I explain Jenkins Post Actions and show you how you can write post actions for your pipelines. If you didn’t read previous articles, read them first. So let’s get this party started.

If you need a ready-to-go Jenkins environment with all essential plugins to implement pipelines, use the following repos available for both Kubernetes and Docker:

https://github.com/ssbostan/jenkins-stack-kubernetes

https://github.com/ssbostan/jenkins-stack-docker

Follow our social media:

https://www.linkedin.com/in/ssbostan

https://www.linkedin.com/company/kubedemy

https://www.youtube.com/@kubedemy

https://telegram.me/kubedemy

What are Jenkins Pipeline Post Actions?

Post Actions are just like other normal stages but run in specific conditions. Jenkins supports 10 special action conditions run when these conditions meet. They are related to run status and can be defined in the post block for the whole pipeline and per stage.

always runs always, as its name says. This post action is not bound to any specific build/run statuses – some actions like sending notifications and saving logs.

changed runs only when the current build’s status differs from the previous one – some actions like sending notifications and running another pipeline to investigate the pipeline.

fixed runs when the current build status is successful, and the previous build was failed or unstable – some actions, like sending notifications or triggering another pipeline.

regression runs in situations where the current build status is failed, aborted or unstable, and the previous run was successful – some actions, such as rollbacking in CD pipelines.

unstable runs when the current status is marked unstable. For example, when the tests fail, or application code coverage is less than the desired percentage. Some actions can be done within this block, like trying other tests and running a lazy canary environment.

aborted runs when the build process is aborted, usually manually. For example, everything that happened before aborting the pipeline should be reverted with this action.

failure runs when the current status of the build is failed – some actions like sending alerts, rollback CD pipelines, deleting intermediate artefacts, etc.

success runs when the current status of the build is successful. Some actions like saving artefacts, uploading them, and triggering the CD pipeline must be done with this action.

unsuccessful runs when the build status is anything except success. This condition is a mix of failure, aborted and unstable status. You can mix and do some related things within this block and avoid repeating them in several blocks.

cleanup always runs after all other conditions are evaluated. All cleanup processes, like deleting intermediate artefacts, logs, temp files, etc., should be done with this action.

The complete Jenkins Post Actions example:

I should remind you that these conditions/blocks can be defined for the whole pipeline and per stage. The post block, defined after the stages block, is evaluated after running all stages, and the post block defined per stage, just after the steps block, is evaluated after running that stage. Where you define these conditions or which condition you need to define depends on your pipeline needs and the aim of the pipeline. In many real-world pipelines, you must define various conditions on the pipeline and per stage.

You can find all tutorial materials in the following GitHub repository:

https://github.com/ssbostan/jenkins-tutorial

If you like this series of articles, please share them and write your thoughts as comments here. Your feedback encourages me to complete this massively planned program.

Follow my LinkedIn https://www.linkedin.com/in/ssbostan

Follow Kubedemy LinkedIn https://www.linkedin.com/company/kubedemy

Follow Kubedemy Telegram https://telegram.me/kubedemy