Brigade 2.2.0

Happy New Year, Brigadiers!

We’re starting the new year off right with our second minor release of Brigade 2.

v2.2.0 continues the trend started with v2.1.0 by delivering just a handful of small, incremental improvements. Notably, in this release, we’ve corrected a bug in the user list endpoint and added an option for script authors to designate jobs as fallible – that is, allowed to fail without forcing the overall workflow defined by the script to fail. This is a great feature for cases where script authors may wish to treat a certain job’s failure as informational in nature rather than fatal.

To demonstrate fallible jobs, consider this small fragment of a brigade.ts file:

events.on("brigade.sh/cli", "exec", async event => {
  let job0 = new Job("test-job0", "alpine", event)
  job0.primaryContainer.command = ["false"]

  let job1 = new Job("test-job1", "alpine", event)
  job1.primaryContainer.command = ["true"]

  await Job.sequence(job0, job1).run()
})

In this example, wherein job0 will always fail, the sequence of job0 followed by job1 will never complete and the worker executing this script will always fail. Workarounds exist, but with fallible jobs, this script requires only the slightest modification to ensure job0 has no bearing on the success or failure of the worker that’s executing it:

events.on("brigade.sh/cli", "exec", async event => {
  let job0 = new Job("test-job0", "alpine", event)
  job0.primaryContainer.command = ["false"]
  job0.fallible = true

  let job1 = new Job("test-job1", "alpine", event)
  job1.primaryContainer.command = ["true"]

  await Job.sequence(job0, job1).run()
})

At the moment, our favorite practical use of this feature is for running yarn audit as part of our CI pipelines on JavaScript and TypeScript projects. While we obviously take vulnerabilities reported by yarn audit seriously, we’ve got Dependabot keeping an eye on those and it is frequently the case that a PR that failed yarn audit did not modify project dependencies, was not responsible for the audit failure, and was merely a victim of poor timing. Rather than allow such PRs to get stuck in limbo while unrelated dependency issues are sorted out, we elect to treat the results of yarn audit as informational only. The following fragment demonstrates:

events.on("brigade.sh/github", "check_suite:requested", async event => {
  const nodeImg = "node:16.11.0-bullseye"
  
  let test = new Job("test", nodeImg, event)
  test.primaryContainer.command = ["yarn"]
  test.primaryContainer.arguments = ["test"]

  let audit = new Job("audit", nodeImg, event)
  audit.primaryContainer.command = ["yarn"]
  audit.primaryContainer.arguments = ["audit"]
  audit.fallible = true

  await Job.concurrent(test, audit)
})

Having now conducted two minor releases in the past month, it’s a good time to address the Brigade team’s expected release cadence. At this time, we’re not committing to any pre-defined release schedule. Rather, we are committing to releasing small batches of incremental improvements on an ad hoc basis. Since we are voracious consumers of our own product and are often eager to use the latest improvements, the Brigade community can reasonably expect minor releases to be frequent in the near term. Of course, we’ll always blog about each release right here, so check back often!

Happy scripting, everyone! And until next time, remember you can always find the maintainers on the #brigade channel on the Kubernetes Slack if you have questions or need help getting started!