Jenkins CLI

Damian Bielecki
Fandom Engineering
Published in
3 min readJun 28, 2019

This article is a part of the series on creating this tool:

At Fandom, Ad Engineering process of testing and releasing our code can be complicated. We have our main library called ad-engine, and a number of platforms that we support. Whenever we change something in the ad-engine we need to:

  1. Update a version of the ad-engine in a given platform.
  2. Deploy a given platform on a sandbox.
  3. Run tests on a given sandbox.

The process is cumbersome because we need to wait for each step to finish before we can proceed to the next one. Moreover, arguments for those jobs can be easily inferred from the context. That’s why we have introduced Jenkins CLI to combat those problems.

Input Arguments

The first part of the CLI handles input arguments.

  • First, it displays a multi-select list with tasks it can execute, then a multi-select list of project (platforms) to choose.
  • Then, it will try to guess a branch based on the repository in which you are when running the tool.
  • Sandbox is a single-select list with a default value that can be set in the tool.
  • Url params take a cache buster equal a current timestamp as a default value.
  • Test tab name is inferred from the branch name and user’s initials.

Of course depending on jobs and projects you selected some of those questions may not appear, and there are also some hidden behind the--extended flag for advanced usage. The bottom line is that in most cases you need only to select jobs and platforms and the rest will be inferred based on the context.

Concurrency

The second part of the tool is actually executing jobs and providing feedback to the user as they go on. This part is way more sophisticated programmatically and I would like to dedicate to this issue two separate articles explaining how it works.

However, for now, let’s discuss it here in less detail anyway.

  • update, deploy, test — are “Job Batches” or simply groups of jobs. Job Batches are executed sequentially, each awaiting preceding one to begin.
  • app, mobile-wiki, f2 — represent actual “Jobs” within a Job Batch. They are executed in parallel and once all are done, a Job Batch is considered done.

So the tool is actually capable, at least in theory, of executing n number of Job Batches with m number of Jobs in them. To do so, one needs to provide input that can be described this way:

Summary

Jenkins CLI has helped us speed up our workflow, and in incoming articles I will explain how it works under the hood, and how it can be incorporated into your workflow.

--

--