In this blog, I will be discussing the basic structure of a Jenkins Pipeline, what a pipeline consists of, and the components used in the pipeline.

You can see the basic overview of a pipeline here, on GitHub.

Let's see the components used in this pipeline in detail:

1. pipeline: A block in which we write the main pipeline we want to create.

2. agent: The agent is where we want our whole pipeline or stages to run.

An agent can have parameters like

• any: If we write agent any then Jenkins will run the whole pipeline or stage on any available agent.
• none: If we write agent none on top of the pipeline then our global agent is not defined and for every stage, we have to define our agent where we want to run our stage.
• label: This means running the pipeline or stage in any Jenkins environment with a defined label.
• docker: To run in a Docker environment.

There are many more agents. If you want to discover all agents, click here. Let's continue talking about pipeline components:

3. stages: This is a block where we write the stage we are writing steps for. A Stages block contains stages like Build, Test, and Deploy.

In this stage, we are authorizing the git repository where my play project is.

4. stage: This is a sub-block inside stages where we define a single stage like Deploy or Build and steps required in each of these stages.

5. steps: In this block, we write all the steps that are required in a stage.

6. post block: A post block is where we write what we want to do when our pipeline has executed.

The post block takes parameters like

• always: This step will always execute whether our pipeline fails or not.
• failed: This step will execute only when the current build of our pipeline has failed.
• changed: This step will execute only when the current state of our pipeline is different from the previous state.

To discover all the steps in the post module, you can refer to the Jenkins documentation here. 

7. triggers: This is used when we want to specify after how much time our pipeline will be triggered. It has parameters like

• cron: It takes a cron type expression to see after how much time a pipeline should trigger itself. To learn more about cron expressions, see here. 

This will automatically trigger my pipeline every five minutes.

• poll SCM: This defines a regular interval after which Jenkins will poll our git environment to see whether there is a change in our source code. If yes, then it will trigger our build.

This pipeline will tell Jenkins to continuously poll our GitHub every five minutes to see if there is a change in our source code. If yes then it will start to execute stages in our pipeline.

8. when: To run a particular stage on the given condition, we use the when block.

The compile stage will only run when the branch on GitHub is the master. If it is a branch other than the master, it will skip this step. To learn more about the when clause and what parameters it takes, click here.

9. sequential stages: A Jenkins pipeline can become quite complex sometimes. We can declare stages inside stages; this structure of writing pipelines is known as sequential stages. Nested stages will run in a sequential order.

10. parallel stage: We can even run our stages in parallel on different machines. Just add a parallel {} block in our stages and our stages will run in parallel on different agents.

I hope this blog was helpful in understanding the basic structure of a Jenkins Declarative Pipeline. If you want to explore more about Jenkins pipelines, you can refer to the Jenkins documentation here.