Introduce image versioning

[peick]

It would be good to have images with a version rather than always overwriting the latest version.

Thus, one could use explicit versions.

My proposal would be to use the date as a version, e.g.

• pypa/manylinux1_x86_64:20170502

[njsmith]

Are you aware that docker gives every image a unique id that you can use like this?

[peick]

Yes, but:

• hashes are not human compatible
• hashes are not comparable
• hashes does not give a hint if it is a stable release image
• most important: old manylinux untagged images are deleted

[peick]

Another point: it would also be good to have a changelog file.

[njsmith]

hashes does not give a hint if it is a stable release image

They're all stable release images.

most important: old manylinux untagged images are deleted

Hmm, that is annoying.

It looks like our build scripts actually do tag every image with the git commit id used to build it, but then I guess that isn't getting pushed to quay.io? We could potentially do that; I don't really understand docker's command line but I'm guessing it would be a trivial change to deploy.sh.

Of course git commit ids are also not human friendly or directly comparable, but they're unique and consistent across the two manylinux image repos. I guess we could use tags like 2017-05-01-ab381ae, and if we took the date from git metadata instead of from the time on the build machine then it'd even be guaranteed to be consistent across the different builds.

Another point: it would also be good to have a changelog file.

git log or the list of merged PRs do a fairly reasonable job at this.

[peick]

It looks like our build scripts actually do tag every image with the git commit id used to build it, but then I guess that isn't getting pushed to quay.io?

There's a docker push call missing in the deploy.sh script. It should look like this:

...
docker tag ${tag}:${TRAVIS_COMMIT} ${tag}:latest
docker push ${tag}:${TRAVIS_COMMIT}
docker push ${tag}:latest

Explaination: A docker build builds an image for the local docker daemon. It does not touch anything on a docker registry even if the name of the image looks like so. The docker push command copies (more or less) the image from the local docker instance into the docker registry.

I guess that there is a setting in your quay.io account, about what to do with dangling images. I'm not familiar with quay at all, but this sounds like the default behaviour to remove such images. On dockerhub it's different.

I guess we could use tags like 2017-05-01-ab381ae, and if we took the date from git metadata instead of from the time on the build machine then it'd even be guaranteed to be consistent across the different builds.

Sounds reasonable.

[cmcginty]

I tried using the docker images hashes, however it seems that the images are not stored for very long which makes the hashes useless. If the images are served from docker hub, is there a retention policy that needs to be modified?

[joerick]

We're looking at introducing support for deterministic builds over at pypa/cibuildwheel#239 , and came across this question too.

I tried pulling an old version from quay.io, but I was given the error 'manifest not found'. I wonder if quay.io doesn't keep images around for long if they're not tagged?