In the previous section you may have noticed the agent directive in each of the examples. The agent directive tells Jenkins where and how to execute the Pipeline, or subset thereof. As you might expect, the agent is required for all Pipelines.
Underneath the hood, there are a few things agent causes to happen:
- All the steps contained within the block are queued for execution by Jenkins. As soon as an executor is available, the steps will begin to execute.
- A workspace is allocated which will contain files checked out from source control as well as any additional working files for the Pipeline.
There are several ways to define agents for use in Pipeline, for this tour we will only focus on using an ephemeral Docker container.
Pipeline is designed to easily use Docker images and containers to run inside. This allows the Pipeline to define the environment and tools required without having to configure various system tools and dependencies on agents manually. This approach allows you to use practically any tool which can be packaged in a Docker container.
For more agent specification options, consult the syntax reference.
Jenkinsfile (Declarative Pipeline)
pipeline {
agent {
docker { image ‘node:7-alpine’ }
}
stages {
stage(‘Test’) {
steps {
sh ‘node –version’
}
}
}
}
Jenkinsfile (Scripted Pipeline)
node {
/* Requires the Docker Pipeline plugin to be installed */
docker.image('node:7-alpine').inside {
stage('Test') {
sh 'node --version'
}
}
}When the Pipeline executes, Jenkins will automatically start the specified container and execute the defined steps within it:
[Pipeline] stage
[Pipeline] { (Test)
[Pipeline] sh
[guided-tour] Running shell script
+ node --version
v7.4.0
[Pipeline] }
[Pipeline] // stage
[Pipeline] }Mixing and matching different containers, or other agents, allows quite a lot of flexibility when executing a Pipeline, for more configuration options, continue to “Using environment variables.”
