Our pipeline is currently building a Linux binary of our application before adding it to a container image. What if we want to distribute the application also as executables for different operating systems? We could provide that same binary, but that would work only for Linux users since that is the architecture it is currently built for. We might want to extend the reach to Windows and macOS users as well, and that would mean that we’d need to build two additional binaries. How could we do that?

How can we create binaries for all three OS?

Since our pipeline is already building a Linux executable through a step inherited from the build pack, we can add two additional steps that would build for the other two operating systems. But that approach would result in go-demo-6 binary for Linux, and our new steps would, let’s say, build go-demo-6_Windows and go-demo-6_darwin. That, however, would result in “strange” naming. In that context, it would make much more sense to have go-demo-6_linux instead of go-demo-6. We could add yet another step that would rename it, but then we’d be adding unnecessary complexity to the pipeline that would make those reading it wonder what we’re doing. We could build the Linux executable again, but that would result in duplication of the steps.

A better solution is to remove the build step inherited from the build pack and add those that build the three binaries in its place. That would be a more optimum solution. One step removed, three steps added. But those steps would be nearly the same, the only difference would be an argument that defines each OS. Instead of having three steps, one for building a binary for each operating system, we’ll create a loop that will iterate through values that represent operating systems and execute a step that builds the correct binary.

This might be too much to swallow at once, so we’ll break it into two tasks. First, we’ll try to figure out how to remove a step from the inherited build pack pipeline. If we’re successful, we’ll put the loop of steps in its place.

Let’s get started.

We can use the overrides instruction to remove or replace any inherited element. We’ll start with the simplest version of the instruction and improve it over time.

Overriding the release pipeline

Please execute the command that follows to create a new version of jenkins-x.yml.

Get hands-on with 1400+ tech skills courses.