Search form

Jenkins, Workflow and Gerrit: Putting the Pieces Together

Today you’ll find out how the workflow plugin for Jenkins can simplify an otherwise complex CI pipeline based on a real world Jenkins customer doing mobile development. During early versions of workflow, plugin support was limited, but with a significant investment of developer effort, wider compatibility now enables workflow to simplify life for many teams.

Specifically:

Workflow support (added to gerrit trigger support in version 2.15)

Workflow failFast for parallel steps (workflow version 1.3)

Broader compatibility enhancements

Out of the box, it now enables functionality that previously needed clever and complex job structuring.

The situation:

To manage multiple code repositories, they use repo, which is similar to git submodules

Extensive sets of tests based on the linux build result, including longer automation tests that run all night

Build/test results should submit results (“votes”) to gerrit so the developer can see everything in one place

Here’s what the overall infrastructure looks like (in Dockerized demo form). Note that the repo has its own repository that contains manifest files which describe repositories, and it provides a manifest that the client-side tool uses to orchestrate results.

Nothing terribly unconventional, but for CI, speed matters! Nothing kills developer productivity more than pushing a bad commit and not seeing the problem until all parts of a long build/test cycle finish… the next day. In this case, any failure in the pipeline counts as a failure for the code change.

So, how do we achieve fast feedback? Parallel execution of steps will reduce the total time to the slowest component.
Here’s what our job structure will look like, with parallel steps enabled:

We must go faster, though! What if we want to send feedback to the developer *as soon* as any failure occurs? Now, the problem: we need *fail-fast* functionality, to report CI results as soon as any step fails. Additionally, we need to make sure that there are no orphaned builds; executors and test environments should not be tied up if one component of the build has failed — automation tests can be expensive to run! As one added fillip, gerrit supports sending information about revised patchsets, and we’d like to kill and rerun the entire flow if someone pushes a revision to their current patchset while the current one is being built.

Unfortunately, freestyle builds do not make this straightforward: traditional job structures to achieve this require 10 separate jobs chained together, and to work with a new branch one has to copy the whole job hierarchy and change branch references.

Every business is a software business, and is under pressure to innovate constantly. This increased velocity introduces new business risks. CloudBees is building the world’s first end-to-end automated software delivery system, enabling companies to balance governance and developer freedom.Learn More