With Docker, we can package our application in a Docker image and we have the assurance that it will run on any machine that has Docker. We can do the same with our build plan. Dockerizing the build environment means that the only dependency we have on the build server is that it supports Docker. This reduces the amount of work needed to manage the build server and enables teams to be more independent.
Update 2018-08-26 See also Dockerize the build plan v2.0
To do that, we’ll need to write a separate
Dockerfile. Let’s call it
Dockerfile-ci. It looks similar to the main
Dockerfile at first:
FROM node:8.9-alpine RUN mkdir -p /app ADD package.json /app ADD package-lock.json /app WORKDIR /app RUN npm install ADD . /app
It has some differences with the main
- it doesn't have an
EXPOSEinstruction, because we're not going to run the application.
- it doesn't have a
CMDinstruction, because we'd like to run any command
- it installs all dependencies, including dev dependencies, which will produce a larger image
To build the image we run:
docker build -t blog-helm-ci -f Dockerfile-ci .
This new image named
blog-helm-ci contains the application code and all of its dependencies and it is ready to run any command we want.
We can use the image to run linting:
docker run blog-helm-ci npm run lint
This is the same as running
npm run lint, but we don’t need to install node on the build server, or having to worry about managing node versions, etc.
Since we’re talking about build servers, when running this on a build server, we’d like to be able to see the linting results in a human friendly way, instead of trying to figure out what went wrong by diving into the build’s log file. We can configure ESLint to generate an XML report with the problems it finds, using the ubiquitous jUnit XML report format.
To do that, we’ll first configure an additional npm script to run ESLint with XML output. In
package.json, we need to add the following in the scripts section:
"lint-junit": "eslint -f junit -o test-reports/eslint.xml .",
This gives us a new npm script,
npm run lint-junit, which will generate an XML report at
test-reports/eslint.xml if there are any linting issues. If we configure the build server to read this file, we will get a friendly report with the problems we need to solve. Note that we can do the same with unit tests, we just use linting as a simpler example.
We’ll need to rebuild the our docker image and then run the new script:
docker run blog-helm-ci npm run lint-junit
And… nothing happened! There is no
test-reports folder at all. What went wrong?
Remember that the commands are running within a Docker container. They are running against the filesystem of that container. So the
test-reports got created fine, but it was created inside the container, not on the physical host (e.g. personal laptop or build server).
Containers are ephemeral; to preserve data, we need to use a Docker volume. We’ll need to define in
Dockerfile-ci that the
test-reports folder is a volume:
VOLUME [ "/app/test-reports" ]
This allows us to mount this folder. The run command looks like this:
docker run \ -v $(pwd)/test-reports:/app/test-reports \ blog-helm-ci \ npm run lint-junit
One small side note regarding user permissions. When running on a Linux server, the test reports will be owned by the root user. This will break the builds, as the build server won’t be able to clean the working directory. There are various ways to solve this, but I find that the least complicated one is to simply fix the permissions manually using our CI image:
docker run \ -v $(pwd)/test-reports:/app/test-reports \ blog-helm-ci \ chown -R $(id -u):$(id -g) test-reports
This will set the correct permissions on the test reports and permit the build server to properly clean up its directories when needed.
There are other options as well, but it complicates the Dockerfile. An alternative that does not complicate code is to use Docker on Docker, which is off topic for this series.
Let’s see how the build looks like in TeamCity:
The build is actually failing because I am using
console.log which violates linting:
After I fix this linting issue, I get a green build:
On the next post, we’ll have a look at creating a Helm chart for this project.
This article is part of the CD with Helm series:
- CD with Helm part 0: hello world app
- CD with Helm part 1: Dockerize it
- CD with Helm part 2: Dockerize the build plan
- CD with Helm part 3: Kubernetes Intro
- CD with Helm part 4: Helm Intro
- CD with Helm part 5: versioned artifacts
- CD with Helm part 6: networking interlude
- CD with Helm part 7: Docker registry
- CD with Helm part 8: DTAP