Building, Testing, and Releasing Updated Containers

How to build new versions of the various D4ST Docker containers.

All the D4ST Docker containers are managed through the Docker Hub web site and are built automatically whenever updates are pushed to each container's associated GitHub repository.

However, rebuildling the containers can take time because Docker Hub is a shared resource.

For local testing you can use the normal docker build command to build a container in order to test changes. While it is possible to use docker-compose to build a set of containers in one go, the D4ST Docker docker-compose files are not set up to do that because usually it's not that useful (because of the use of Docker Hub to manage official builds).

You also need to be careful that you're running the right container instance: it's easy to build a new container but still run an old image locally. The d4st command includes options to clean up all D4ST containers and all D4ST images, which can be useful to clean up your local environment before doing local builds.

To do a full release-time regression test you should do the following:
  1. Merge all changes to the project's "develop" branch and otherwise ensure that everything appears to be working as it should.
  2. Push all the projects's "develop" branch to GitHub. This will trigger rebuilding of all the containers on Docker Hub. You can use the Docker Hub web site to check the status of the automatic builds. The result will be new images for the "latest" and "develop" tags.
  3. On a different system, ideally a Windows machine, do a "d4st pull" to get the latest containers and then d4st start followed by any operational tests you need to do to verify the functionality.

For a release, create a tag reflecting the release number in each git repository and push them to GitHub. This will again trigger creation of containers that reflect the tag name.

Create a new D4ST Docker release package and create the release on the d4st-docker GitHub project.