Give Codeship a try

Want to learn more?

Earlier today, Codeship announced support for build arguments on our Codeship Pro platform. You can read the announcement here.

Build arguments allow you to pass custom values to your Docker image during the image build process. Unlike environment variables, these values won’t be persisted to the build image, making them a great way to customize your image build process if you know that the variable isn’t needed at runtime. A few examples where build args come in handy are accessing private assets, like a private gem server, or passing in a path that may change from build to build.

Codeship Pro services use build arguments in the same way that Docker does; in fact, the arguments you provide are passed directly to Docker running on your build machine. If you’re interested in learning more about using build args with Docker specifically, you can read through their documentation. I’ll walk through an example using a service in a Codeship Pro build below.

Let’s say we want to pass a version number to the image as the variable VERSION. Since this changes with each commit to master, we can’t hardcode it in the Dockerfile as an environment variable. Instead, we can use a build argument that will allow Docker to use the value when the image is built, but not persist it to the final build image (meaning we can’t access it at runtime).

To consume build arguments during a service’s build process, you must first update your Dockerfile. This essentially creates an unset variable, and lets Docker know that it should expect a value to be passed in at build time.

Note: To follow along with this example, you must download the latest version of the Codeship Jet CLI, which includes support for build arguments.

The VERSION variable is missing, because build args aren’t available at runtime.

Build arguments can also helpful in the case that you want to access private assets during your image build. Because you don’t want these arguments in your repo in plain text, Codeship supports encrypted build arguments as well. To encrypt a file with build arguments, you’ll need to download the local Codeship Jet CLI and get your Codeship Pro project’s AES key from the Project Settings page.

Create a file called build_args.env. It might look something like this:

GEM_SERVER_TOKEN=XXXXXXXXXXXX
SECRET_BUILDTIME_PASSWORD=XXXXXXXXXXXX

Take care to use KEY=value syntax instead of key: value in this file. Using the Jet CLI, encrypt the file.

jet encrypt build_args.env build_args.env.encrypted

Then, include that file in your build directive for the service that consumes it. Note that you still need to add the ARG instructions to your service’s Dockerfile in order to use the encrypted arguments.

Codeship will decrypt your build arguments and pass them to the image at buildtime as an unencrypted value.

Note: Docker advises against using build arguments to pass in any sort of secrets to your images, as they can be seen when inspecting the image layers. This is great advice for production environments, but during CI/CD with Codeship all your builds run in a single-tenant environment, and no other user or machine has access to your build machine. Your machine (and everything on it!) is also destroyed after each build, never being reused. Because of this, it is advised to use build arguments necessary for the CI/CD process on Codeship while being sure not to deploy images to production that use them in the same way.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles. Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

Hey Max, I definitely agree, and thanks for the feedback. We have some upcoming projects to address that (both making those CI vars available as build arguments, and better environment variable support including interpolation in the yaml files). I’ll make sure your feedback gets to our product team!