Public | Automated Build

Last pushed: 9 months ago
Short Description
Changing name-space to bettermarks
Full Description


  • The github repo is directly linked to using the same details as docker-hub credentials (check admin wiki)
  • Every branch/commit pushed to github creates a tag with the name of the branch. (Sometimes it takes some minutes for the build to take place because it gets queued)
  • Image namespace is bettermarks/docker-build-tests, when merging to master the tag bettermarks/docker-build-tests:latest is created/overriden.

content of the image

  • This image also includes yarn
  • Builds the node js image with required dependencies on the docker image
  • all dependencies required to install node-sass and canvas

using alpine images / updating Dockerfile

We reduced the image size be building on top of alpine version of node docker images.
This requires to (explicitly) install in some packages to be able to npm/yarn install certain node dependencies.

The one dependency that this was tested with is canvas. As soon/long as we don't need canvas support for running tests inside docker, we might be able to drop most of the additionally installed packages.
(Some might still be required for other dependencies using npm/yarn install, that compile code during install.)

For being able to test that the image will work this is the procedure:

  1. enable last line in the docker file to test that js dependency can be installed. (For the version currently in use I last checked the package.json in the project bm-renderer-core, which might by now already be outdated.)
  2. run docker build . to create a local version of the image
  3. once you are done making changes to the Dockerfile, disable the last line again and commit your changes. (As stated above dockerhub is configured to build a new version of the image automatically for usage in CI.)

Testing the image

Docker Hub provides automated testing facilities through Docker Compose files:
Any files in the same folder as the Dockerfile that end with .test.yml will be considered a Compose file to be used for testing.
Docker Hub will perform a one-off execution of the sut service. This is where your test scripts are executed. Its return code is used to determine if the tests passed or failed.

(partly copied from a blog post and the related github repoabout how to do the same for more complex testing and more CI systems.)

We are using docker-hub.test.yml to add tests.

  • add some library globally, that have build time dependencies to the OS.
  • create an empty project and do some basic setup to test the folder structure works as expected

For finding libs that need dependencies you can run grep -lr 'postinstall' node_modules inside the project.

For running the tests locally that Docker Hub runs (this will report but not return the exit code of the test):

docker-compose -f docker-hub.test.yml up --build
Docker Pull Command
Source Repository