Images may be unversioned

[giorgiosironi]

In case someone else run into this, for example mailcatcher only contains a latest tag which means automated builds using it may lead to a different results as that tag evolves and a new version is pushed. The list of versions contains tens of different versions that have all been overwritten on the same tag.

[OlivierCuyp]

The issue is that all the dockerfiles are stored under the same repository.
So there is no way to add tag for individual image through Docker Automatic Builds.
If we had tags they would apply to all the images.
The only way to me would be to create a repository per project.
Maybe @schickling have an other idea on this...

[laszlof]

This bit us in the butt as well. You changed the beanstalkd dockerfile to use ENTRYPOINT rather than CMD. We were using the box with the Vagrant docker provider, and passing in a custom cmd option to add parameters (specifically the -z param).

Versioning would have fixed this. though I see your problem with having them all in one repo.

[OlivierCuyp]

Agreed that versions would have been very nice.
We try to avoid compatibility break as much as possible but changes have always hidden side effects.
Sorry about that.

[giorgiosironi]

FWIW in https://github.com/elifesciences/elife-base-images we apply tags based on the commit sha, which is unreadable but at least guarantees to unambiguously identify every new image being pushed:
https://hub.docker.com/r/elifesciences/python/tags/

[giorgiosironi]

Another option is to tag with a date like 20180731 or 2018073111900, which is slightly more understandable.

[OlivierCuyp]

@giorgiosironi thanks for your advice.
I believe you use Jenkins to build and push your images on DockerHub.
This gives you more control than us since we are using DockerHub Automated Build.
In our, case we can only tag on github release.
But as I said in a previous comment all our images would get the same tags even if they didn't change.

[tholu]

@schickling Any plans to tag images with versions?