Zuul 3, a modern solution for CI/CD
Continuous Progress
Nodepool
The last of the crucial Zuul 3 components to be explained is Nodepool, a service that keeps the configuration of hosts where jobs are being executed. Apart from static nodes, you can define providers that launch instances in a chosen cluster as needed. Available drives are for OpenStack, Kubernetes, OpenShift, and Amazon Web Services (AWS), but in addition to the official drives, a few exist off the record (e.g., for oVirt or Proxmox).
Configuration
The entire Zuul configuration is written as YAML files. A job
(Listing 1) is a group of strictly related tasks to perform to decide whether a change is valid or not. The main job elements are:
name
– A unique project identifier.parent
– A job's configuration can be inherited; therefore, all common elements should be kept in one job, and only needed elements should be overwritten. List elements are inherited additively (e.g.,pre-run
andpost-run
lists are added to those in the base job), whereas others are inherited (e.g., a timeout value).pre-run
/post run
– These lists are playbooks that are always executed. Pre-runs prepare the environment, and post-runs usually collect artifacts.run
– This element comprises a list of playbooks that perform the verification and are executed until the first failure or all in the list have been run.nodeset
– The nodes where the job should be run.
Listing 1
sample_job.yml
- job: name: compilation parent: base pre-run: playbooks/base/pre.yaml run: - playbooks/compilation.yaml post-run: - playbooks/base/post-ssh.yaml - playbooks/base/post-logs.yaml timeout: 1800 nodeset: nodes: - name: main label: compilation_hosts
Other elements can be defined in a job that modifies its behavior, like a timeout in seconds or ignore_error
, which returns success, regardless of the job's real result.
Pipeline
The pipeline
entity (Listing 2) describes conditions, jobs, and the results of a change. The main pipeline elements are:
name
– A unique name for the Zuul tenant.manager
– The relation to other ongoing changes for a given project (e.g.,independent
means that this pipeline will run independent of any other change). This config is useful for the initial verification of each patchset. Another value here informs Zuul that it takes into consideration the output of another pipeline.trigger
– In this example, the trigger defines the factors that start execution of the pipeline for Gerrit. In this case, it waits for a new patchset (or new review) or comment by a reviewer with the text RECHECK .success
/failure
– These configs determine what Zuul should do, depending on the result. In Listing 2, aVerified
vote of +1 or -1 is reported to the MySQL database.require
– The pipeline will not run if these additional conditions are not fulfilled (e.g., here, I do not want to check already closed reviews).
Listing 2
sample_pipeline.yml
01 - pipeline: 02 name: verification 03 manager: independent 04 description: | 05 This pipeline is only to learn how Zuul works 06 trigger: 07 gerrit: 08 - event: patchset-created 09 - event: comment-added 10 comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*RECHECK 11 success: 12 gerrit: 13 # return to Gerrit Verified+1 14 Verified: 1 15 # return data to MySQL (empty key here 'mysql:') 16 mysql: 17 failure: 18 gerrit: 19 Verified: -1 20 mysql: 21 require: 22 gerrit: 23 # prevents waste runs on %submit usage 24 open: true
Buy this article as PDF
(incl. VAT)