Quote from ljunggren on October 7, 2020, 6:22 pm

Introduction

We have introduced Semver versioning for our Boozang-runner for CI integration. The versioning approach is based on the article by Marc Campbell

https://medium.com/@mccode/using-semantic-versioning-for-docker-image-tags-dfde8be06699

and Travis Reeder

https://medium.com/better-programming/how-to-version-your-docker-images-1d5c577ebf54

We also uses Travis's Docker package to bump version numbers

https://github.com/treeder/bump

Why version?

Doing proper release management for your code is crucial. At the start, we weren't sure this would be necessary for the Boozang runner, as this is a Docker container that rarely changes.

We assumed we could simply keep updating the Boozang runner and we would make sure that the latest would always work. This was true for most of the time, but became a problem as soon as we had to delay a code release. Let's say we are working on master, and update the Boozang test runner to be compatible with the latest code. When we post-pone the release (let's say it doesn't pass regressions) the Boozang test runner will be ahead of the code, which can break things. 

This is especially problematic for users that always retrieve the latest Boozang runner in the CI jobs, and not manually when specified in the release notes.

docker pull styrman/boozang-runner

This implicitly means getting 

docker pull styrman/boozang-runner:latest

which in our case would be any version of the container regardless of release or release tagging. We understood that we would have to wait for a code release to be deployed before tagging the Boozang runner accordingly. 

Semantic versioning

By introducing a type of Semantic versioning as Docker tags, we can introduce lightweight release management for our Boozang runner. 

This means allows for better control when retrieving the Boozang runner. This allows the user to get the latest "pre-production" release, the latest release, and even to access previous releases. The version is saved in a separate version file VERSION containing '$major', '$minor', and '$revision' version numbers, like

2.0.2

Then we use the following code to tag the container

# Release container

# Some build code

# bump version
docker run --rm -v "$PWD":/app treeder/bump patch
version=`cat VERSION`
echo "version: $version"

major=`echo $version | cut -d. -f1`
minor=`echo $version | cut -d. -f2`
revision=`echo $version | cut -d. -f3`

# tag it
docker tag $USERNAME/$IMAGE:latest $USERNAME/$IMAGE:$version
docker tag $USERNAME/$IMAGE:latest $USERNAME/$IMAGE:$major
docker tag $USERNAME/$IMAGE:latest $USERNAME/$IMAGE:$major.$minor

# push it
docker push $USERNAME/$IMAGE:latest
docker push $USERNAME/$IMAGE:$version
docker push $USERNAME/$IMAGE:$major
docker push $USERNAME/$IMAGE:$major.$minor

This way, we now have flexibility when fetching the latest Boozang runner.

Fetching the container

Previously, the way to fetch the latest Boozang runner would be 'docker pull styrman/boozang-runner'. This will still work, but is not recommended in a production setting. We now have a set of commands that can be used instead

# Get latest Boozang runner, even un-released
docker pull styrman/boozang-runner

# Get latest released Boozang runner of major release VERSION
# Recommended for most. Get's any 2.x.x release. 
VERSION=2
docker pull styrman/boozang-runner:$VERSION

# Get latest released Boozang runner of minor release VERSION
# Not so useful. Get's any 2.0.x release. 
VERSION=2.0
docker pull styrman/boozang-runner:$VERSION

# Get exact revision VERSION
# Leaves you to manually upgrade Boozang runner
VERSION=2.0.2
docker pull styrman/boozang-runner:$VERSION

You can now pick which upgrade procedure works for you. Hopefully, this will better cater to different ways of working, and stability requirements. 

Note: If there is a breaking change in a code release that needs you to update the Boozang runner, this will be stated in the release notes.