Better version management of docker images and support for updates

[simonclausen]

As is now, we build an image, do some tests and push it to a specific version tag on Docker Hub. A new version of dnscrypt-wrapper in an image would get a new tag and be made available under that tag.

This simplified versioning assumes we're okay with having more or less whatever version of Debian and libsodium in the image as whatever is available at build time is what is used.

You are now able to select the version of dnscrypt-wrapper you want to run. Great.

However, e.g. version 0.2.2 will sit there and not receive any patches or updates, when we start tagging images resulting from builds with never versions.

We should take care of this by doing the following:

• Deciding upon how long we want to support updates for older versions of dnscrypt-wrapper
• Redesigning the way images are built, tested and pushed to Docker Hub to allow for multiple versions/dockerfiles/tags to be maintained in parallel
• Designing and implementing periodic builds that support with ongoing update of images

Some notes and thoughts:

• Stay with only defining major version of the source debian image and install only security updates during the docker build
• Use travis-ci's cron functionality for kicking off patch builds weekly: https://docs.travis-ci.com/user/cron-jobs/
• Maybe limit anything but the newest version to be build upon pushes to master (i.e. "if $TRAVIS_EVENT_TYPE = cron" on old versions)

[kidmose]

+1 on the "note and thoughts"

The tag on docker hub can be a version like "x.y.z", with x and y being major and minor version ofwrapper/proxy/... and z being an incrementing serial number for each patch rebuild we do of the image.

[simonclausen]

I'm not entirely sure I see why we need to track build version.

Of course my assumption here is that things will rarely break and if they do, tests should catch them before the updated image is put on Docker Hub.

How would a user of the image experience not seeing changes in the tag?

I would guess Docker checks the layer checksums rather than just compare the tag on the local image with the one on hub, so changes would be pulled, same as the "latest" tag works.

That would leave a user with not having to worry about switching versions/tags to get the newest patches.

[simonclausen]

Update - @kidmose and I have talked around this and come to the following conclusion:

We want to tag with version and version.travis_build, as well as "latest" on the newest version and build. Thus the version tag will be moving with new build making it easy to get a patched version of the image as well as having the possibility to specifically select a version and build if needed.

[kidmose]

Extending with a made up example, if for nothing else, then for my self to be able to remember;
LATEST: points to the most recent cron build of the highest stable release of dnscrypt-wrapper
0.2: Points to the most recent cron build of dnscrypt-wrapper 0.2
0.2.2: Points to the most recent cron build of dnscrypt-wrapper 0.2.2
0.2.2.51: Points to the build of 0.2.2 which was build number 51 on travis

This provides:

• Extendability as new version dnscrypt-wrapper is released
• Enables referencing most up to date build (LATEST)
• Enables referencing most up to date build of specific minor/major dnscrypt-version
• Enables referencing specific builds, with link to build log.

[simonclausen]

Yes, spot on, with these further details:

• The newest version will also be built on "commit to master" basis, with the same tagging
• The additional build tag will also be used on cron builds