pipeline {
agent {
label 'master'
}
stages {
stage('testing 123') {
steps {
sh 'echo hello from master node'
}
}
}
}
In the examples above, you will have seen the agent
directive in use for all Pipelines.
It is required for all Pipelines even if any agent
.
As a distributed system most work a Pipeline performs is done in the context
of one or more nodes. Defining a node
or agent
does two things:
Schedules the steps contained within the block to run by adding an item to the Jenkins queue. As soon as an executor is free on a node, the steps will run.
Creates a workspace (a directory specific to that particular Pipeline) where work can be done on files checked out from source control.
There are several ways to define agents to use in your Pipeline.
This is useful for when you want to specify a particular machine size, or requirement. Use agent { label 'windows' }
to specify that you want your build to run on an agent that has been labelled as windows
. If you make this label ''
then it will run on any agent connected to your Jenkins master that is available.
Example (will use the master
node):
pipeline {
agent {
label 'master'
}
stages {
stage('testing 123') {
steps {
sh 'echo hello from master node'
}
}
}
}
Declarative Pipeline is designed to easily use Docker images and containers to run inside. This allows the Pipeline to define the build and test environment and tools required without having to manually configure various agents. This can pretty much be any image you like, your build steps and stages will run inside it.
Example:
pipeline {
agent {
docker { image 'node' }
}
stages {
stage("testing 123") {
steps {
sh 'node --version'
}
}
}
}
You can also use a Dockerfile in your source repository - with agent { dockerfile true }
, the Dockerfile at the root of your repository will be built and the resulting image will be used for a container your build will run in.
Example:
pipeline {
agent {
docker {
image 'node'
}
}
stages {
stage("testing 123") {
steps {
sh 'node --version'
}
}
}
}
In this case, put agent none
as your agent directive. Pipeline won’t try to find an agent to run on, or pull any Docker images. Inside your stage ...
directives, you will need to specify what node
to run on, should you need one.
Example:
pipeline {
agent none
stages {
stage('say hi') {
steps {
echo "I don't need no node"
}
}
stage('build') {
agent {
label 'master'
}
steps {
checkout scm
sh 'echo from master'
}
}
stage('deploy') {
agent {
label 'deploy-host'
}
steps {
sh './deploy-code-here'
}
}
}
}
In this case, we have a few stages. The last 2 actually get different nodes to execute on (a node is a machine that is running the Jenkins agent). Note the checkout scm
step - this actually fetches the code into the nodes workspace (previously it was done automatically for you).