add env hook to dynamicaly get version string

[duncdrum]

With this PR tags for full releases are no longer hard-coded, but created dynamically. We could do something similar for the develop branch if we had a tag that would indicate the current SNAPSHOT version there. This does not cover RCs on purpose. The docker build procedures between major versions is not always compatible see #14

Please just add your review comments, i need to disable some stuff on dockerhub to make sure it works as expected there as well as here. So if you guys are ok with the changes, i ll do that and then merge myself, to ensure all is peachy.

[duncdrum]

The hooks folder is about configuration for automated builds on dockerhub. Hooks on root won't be executed by the automated build on dockerhub, which also provides $IMAGE_NAME among a a few others, see the docs. They are not supposed to be executed by users.

We could certainly add MAX and CACHE to one of the hooks, but I m actually trying to be more DRY. Having them in the dockerfile, is necessary if we want to keep these settings user configurable in a no shell container. The Dockerfile currently provides defaults, if no build-arg is supplied, so i don't see what we gain by adding them to the hooks.

To execute the hooks locally one has to run CHMOD 750, I did that during testing, however they should only be used by the automated builds on dockerhub which seem to be doing fine with the default file permissions.

I m not married to the labels, as they are only used by microbadge. I would like to clean them up in the dockerfile, but I would like to make sure that the new hook is running properly first. see #19 We have a number of fallback instances that could be the real source of the version tag, however I can only be sure that the hook is working, once I ran a full build on dockerhub with the fallback's disabled, and the new hook merged.

[grantmacken]

Ok l would merge, then. I'm not sure if the git ref will resolve in hooks/env, but try it out.

[adamretter]

A couple of questions:

1. Can we still run builds locally? or is this now not possible without having a rel_ver environment variable?

2. Are we using the same versioning pattern as the eXist-db releases?

3. Why not also RC's - they are just another release with a slightly different version number.

[adamretter]

Regards the develop branch comment:

We could do something similar for the develop branch if we had a tag that would indicate the current SNAPSHOT version there.

The SNAPSHOT version label is just generated from a timestamp of when then build is initiated. You can actually see how we determine all the version numbers here: https://github.com/eXist-db/exist/blob/develop/build/scripts/git-support.xml#L16

[duncdrum]

@adamretter

• local builds are unchanged, as described in the readme
• the regEx takes the tags which describe a full release and extracts the version number from it
• because the dockerfiles for release and develop are not necessarily identical, when there are major version releases. Which is pretty much the only time exist does RCs
• there are no snapshots tags pushed to GitHub, at least the ref command doesn't find any (if we were to add them as part of the release procedure for exist (not a bad idea imv) we could automagically retrieve them here.