UI Testing with Nightwatch.js, Headless Chrome, and Docker: Part 2

AWS CodeBuild vs. Travis CI

In Part 1, I discussed running Selenium and Chrome headless mode on Docker. Originally the plan was to use AWS CodePipeline and AWS CodeBuild to run the Docker container and the smoke tests for my website.

Everything was running great in the Docker container on my machine. Then when I tried to run it on AWS CodeBuild I got this error:

Build container found dead before completing the build. Build container died because it was out of memory, or the Docker image was missing glibc

Dead!?! Oh man… what can we do? The error is pretty vague and doesn’t make a lot of sense. I’m pretty sure I have enough RAM and that I have glibc. I tried a few things, including scouring Google and explicitly adding libglib2.0 to the apt-get installs at the top of my Dockerfile. Then I just removed everything besides the base install and started adding it back again until I narrowed down the offending line, which turned out to be:

USER headless

All this does is switch from root to the user I created. So if it’s not run as root it doesn’t think it has glibc? OK… but either way now I’m seeing a new issue. The Selenium server is running fine on my local Docker container but not in AWS CodeBuild.

At this point I decided to leave AWS CodePipeline and AWS CodeBuild and find another CI server. At first I thought AWS CodePipeline seemed really cool, but it began to feel limiting.

AWS CodePipeline

After looking through some of the several options out there, I settled on Travis CI. I was actually using Travis already for one of my libraries. In my opinion it’s nicer than AWS CodeBuild, so going back to it was an alluring thought.

Travis CI

I had never used Docker before with Travis though. As with AWS CodeBuild there were some differences from when I ran it on my local machine. However, I found an amazing tool called WWTD (What Would Travis Do) which lets you simulate how Travis will act when you run the build. This sped up things significantly.

One issue I had with Travis is getting it to upload the build artifacts (the result of npm run build) to AWS Elastic Beanstalk. By default it just uploaded the original source code from GitHub, and its documentation isn’t that clear about how to deploy build artifacts.

I found though if you zip the contents of your build folder and then specify the zip_file field in the .travis.yml file, it works. According to its source code, Travis creates a zip file behind the scenes if you don’t specify one, so it’s expecting to deploy a zip file anyway.

Here are the relevant parts of the .travis.yml file:

script:
- docker run --name dc kenfehling/node-selenium-chrome:latest & sleep 1
- docker cp server dc:.
- docker exec dc bash -c "cd server; npm test"
before_deploy:
- cd server; zip -qr ../server.zip .; cd ..
deploy:
provider:
elasticbeanstalk
skip_cleanup: true
zip_file: server.zip

This was kind of a wild ride. I started out with AWS CodeDeploy and AWS CodeBuild and moved to Travis CI. In the end it was kind of a lot of trouble to go to for couple of smoke tests, but it was an enlightening experience. Docker is really cool and a fun way to play with Linux. I’ll definitely be using it for more things in the future.