Triggering
Seed jobs and pipelines are triggered using events on some connectors.
Four events are currently supported by the Seed plug-in.
Whenever a branch is created in a project, the creation event is sent, with as a parameter the name of the branch.
The project seed job is triggered for the given branch, in order to create the associated branch seed job.
Whenever a branch is deleted in a project, the deletion event is sent, with as a parameter the name of the branch.
The branch seed job is deleted. The associated pipeline is deleted or not according the configuration of the plug-in.
Whenever the Seed files are updated in a branch (files under the /seed folder), the branch seed job is triggered, in order to regenerate the pipeline, if this configuration parameter is enabled.
Whenever some branch files are updated (outside of the Seed files), the branch pipeline start job is triggered.
The way to send events to the Seed Jenkins plug-in can done using connectors.
Two connectors are supported, but other ones can be added using extensions:
When a hook sends a push event, it will also pass the information about the commit to build.
The Seed plug-in will extract the commit information from the event and pass it to the start of the pipeline using the COMMIT job parameter. This is the responsibility of the pipeline start job to use this information (see examples below).
The
COMMITparameter can be changed using the Event parameter which contains the commit configuration parameter (REVISIONfor a Subversion based project for example).
No specific configuration is needed at Seed level since the default COMMIT parameter sounds like a good default.
A pipeline start job will typically include the following DSL script:
scm {
git {
remote {
url PROJECT_SCM_URL
branch '${COMMIT}'
}
extensions {
wipeOutWorkspace()
localBranch BRANCH
}
}
}Note that the
${COMMIT}is in a single quote string - it must not (and cannot) be resolved at pipeline generation time.
In a Subversion based pipeline, it might be a good idea (or not) to replace the COMMIT parameter by a REVISION one. This is not at all compulsory and using COMMIT is just as fine.
To use REVISION instead of COMMIT, configure the Seed this way:
A pipeline start job will typically include the following DSL script:
scm {
svn {
location("${PROJECT_SCM_URL}/${BRANCH}@\${REVISION}") {
directory '.'
credentials PROJECT_SCM_CREDENTIALS as String
}
}
}Note the escaping for the
${REVISION}parameter - this parameter is used only at runtime, and not at pipeline generation time.
By default, triggering the project seed will of course create a branch seed but also trigger the branch seed immediately after its creation.
If you want to disable the branch seed to be fired immediately, you can set the Regenerate pipeline when seed files changed parameter to No.
If you want to start the pipeline upon (re)generation, you have to define this behavior directly in the DSL script or pipeline library.