version BASE image

[duncdrum]

BASE image only has :latest we should use a properly versioned BASE image

[duncdrum]

@dfukagaw28 we would very much like to use your image as a base for our production environment. I m a bit concerned about the lag of tags on your image though.

The code changes needed for tagging images are minimal, but before i open a PR could you signal us if you d consider tagging your images?

[dfukagaw28]

Sorry, I haven't considered tagging my images. I would welcome your PR!

[duncdrum]

@dfukagaw28 sorry for the delay i was on holiday. In order to proceed we need to

1. Decide on a Versioning scheme for the images Currently iipsrv is at version 1.1 while the docker images can be whatever we want them to be, e.g. 1.0.0 we should avoid confusing users as to which version the version number in the docker tag refers to.
2. Decide where the tagging should take place. Currently tagging is done on docker hub, so i suggest to stick with that. Alternatively we could use travis or github actions to add tags on github. The tagging on docker hub cannot be changed via pull request on Github, see below.

As for the versioning scheme: Currently latest is the only tag available, I would leave that as is, since its best practice to use it, and changing it would break backwards compatibility. Your also repo inherits git tags from the source repo of the form iipsrv-X.X.X these are the iipsrv releases and we should leave them alone. To create docker releases I would suggest to simply adopt a separate git tag convention, e.g. v-X.X.X. And then add two tagging rules in the auto build configuration on docker hub.

The first rule will trigger new images to be releases, based on the upstream releases of iipsrv their tags will take the form release-X.X.X matching the version of iipsrv. The second rule would push new container images for use as base images depending on the development in your repo, the tags would take the form v-X.X.X. Tags coming from upstream will be pulled whenever upstream changes are merged back into your fork. To create a new docker release of your images, simple git tag -a v-X.X.X -m "Container version X.X.X" followed by git push. As long as your tag names start with a v- followed by a version number new images will be tagged and release via docker hub.

Tags of the form iipsrv-X.X.X refer to upstream releases, tags of the form v-X.X.X refer to your releases. Here are the settings, which you can adopt on docker hub under Configure auto builds

My docker hub user name is identical to my github name you can find me here. In order for me to add tagging as part of docker hub auto builds you would need to invite me as a collaborator. In order to allow me to push tags to your github repository you would need to invite as a collaborator on Github in addition to being a collaborator on Dockerhub.

So let me know what you think, or what kind of versioning scheme you would prefer. I m open to suggestions.

[dfukagaw28]

Thank you for the detailed advice, and sorry for my late response.

Actually I had already tried the first rule before, but it did not work because of the lack of Dockerfile. This time I made a new branch releases, in which I made Dockerfile for the upstream releases. Upcoming releases will be merged into releases branch. I hope it would work.

Currently I don't feel the need of the second rule.

And, I have just invite you as a collaborator so that you can help me anytime :-)

[duncdrum]

@dfukagaw28 thank you very much, i did not receive an invite, did you mean to add me on dockerhub or here on github? I notice that the :latest tag is currently out of date and i would like to fix that.

[dfukagaw28]

@duncdrum I added you on dockerhub.

[duncdrum]

ah wonderful, thank you. I can do with push and pull access, but in order to modify the autobuild settings i would need higher privileges. I was looking to modify them and don't have access yet.