Headless Ember Tests in GitLab with Docker

4 min readFeb 10, 2019

My goal was to run my Ember tests in our (in-house, private) GitLab pipeline, but without duplicating the setup steps already encapsulated in our Dockerfile for building the production app. There were a number pieces I had to puzzle over to get this running, this being my first attempt while learning how GitLab CI works. I’m no expert here, so please comment if you have similar experience to share. Here’s the high-level steps I wanted to cover:

Start with our Dockerfile that installs NGINX, builds our Ember application and copies the built distribution to /usr/share/nginx/html.
Our deployment ENTRYPOINT for the image is “nginx” in this example.
To keep the GitLab CI script small and avoid any setup duplication, run the unit tests with the same docker image we just built.
Collect the unit test report in GitLab CI as a build artifact.

Readying the Testem Configuration

The testem.js file in your ember project specifies command-line options that are passed to this executable. Note in the testem.js file below the process.env.TRAVIS variable; this is something we’ll have to ensure is set to true in our Dockerfile. Another couple changes I made to the default are:

Setting the report_file so I can later collect the test results
Setting tap_quiet_logs so error cases are much easier to pick out of the log.
Your CI may have support for a different reporter, such as junit format.

Example testem.js configuration file.

The Dockerfile for Headless Testing

The first problem in getting the Dockerfile ready was finding an example of installing Chrome in an alpine-based Node.js Docker image — most seemed to be for Ubuntu-based images, using apt-key, which isn’t available here. The full Dockerfile is below. It does the following:

Installs NGINX.
Installs Chromium. You may not require freetype or harfbuzz with a newer Alpine base; mine was not the latest and didn’t work without those.
Locates the executable. Using Chromium over Chrome-proper meant that testem.js couldn’t find the executable since it is configured by default to look explicitly for ‘google-chrome’. Easy to solve with RUN ln -s /usr/bin/chromium-browser /usr/bin/google-chrome. (I imagine you could probably do this with an environment variable flag to specify the right executable in the testem.js file too.)
Set the CI environment for Testem: ENV TRAVIS=true

The rest of the file just does the expected basic building of the application distribution and copying it over to the appropriate directory for NGINX to serve it up.

Example Dockerfile that installs Chromium

Kicking off the Tests from GitLab

To use the same image to run the tests, my gitlab-ci.yml script took these steps:

Built the production image
Made a directory for the test report
Ran the tests in the container, by overriding the original ENTRYPOINT

Putting that all together, we get:

Example gitlab-ci.yml file.

Next Steps

This isn’t really the final ideal picture, mostly due to GitLab being completely new to me. Some next steps:

Chrome is essentially bloating the docker production image. Could I use a Chrome service image instead to avoid this, instead connecting to a chrome external to the image? Again, in GitLab, and I suppose because I’m running via the docker image, I don’t have the luxury of TravisCI’s addon: chrome option.
Split the build and test stages. I still need to add the steps for pushing the image to our registry — at which point I could pull it back down in a separate ‘test’ stage. This was the original impetus to figure out running the alternate --entrypoint (rather than simply running the tests in the Dockerfile itself.)
Upgrade our version of GitLab to get the built-in test report support.

If you have any suggestions, tips, etc., please share them.

Photo credit: https://flic.kr/p/pZXF4j

Press enter or click to view image in full size