Use branches instead of tags for the container version

[deviantintegral]

The Docker container is currently wired up to Docker Hub so that any time the parent Drupal container is rebuilt, a new version of our container is built too. This is good, so that we get Drupal and other system security updates automatically.

However, it turns out that Docker will only rebuild automatically for branches, and not tags. It makes some sense to me, as that ensures a tag remains identical unless something is pushed over top.

However, this means when a module specifies a tag of our testing container, they are stuck on a specific version.

My current thinking is we meet Docker half way. For each tag we create, we also create a branch such as 0.1.0-latest. By default, we point our container in config.yml to that tag. From our side, we never change that branch unless something upstream breaks our Dockerfile.

Any other ideas @juampynr ?

[juampynr]

Does Docker support semantic versions? I wonder if we could build the image, tag it and push it ourselves to the docker store. Perhaps I still don't understand how docker does tagging so pardon me in advance if what I say it does not make sense.

[deviantintegral]

Ideally, docker containers use semantic versions, but they aren't a requirement.

Docker even will let you overwrite a tag, but I think that's confusing in the long run. For example, today we build and tag 0.1.0. Tomorrow, Drupal 8.4.3 is released with an SA, and we want to be sure that's used. The only way with tags to fix that is to either overwrite the tag, or to require modules update the tag in their circle config file.

If we create a branch off of 0.1.0, then docker hub should rebuild that branch. That would mean modules would specify a container version like 0.1.0-latest, which would imply "the latest upstream dependencies plus our 0.1.0 tag".

Does that make more sense?

[juampynr]

Not really, I am afraid. What about this screen? Does it imply that if you create and push a tag that matches a particular format, then Docker will build an image out of it with a matching docker tag?

[deviantintegral]

Yes, exactly. We have that set up today. What I'd like to do is set it up so there's a "branch" format that has semantic meaning beyond master. I'm going to try it today.

[deviantintegral]

I've added a build rule:

Now, we need to see if Docker Hub rebuilds that branch automatically later, without us having to push. As long as we see a build past the date of this comment, we know it's working and can update the setup scripts.

[deviantintegral]

Builds still haven't been working, so I did some further investigating.

I found this comment from 2015 which says that linked repositories only cause builds for autobuilds without regexes in them - which would explain why we're only seeing master / latest getting built. I added specific builds for 0.1.0-drupal83 (a tag) and 0.0.10-latest (a branch) and manually built them. Let's see if they get updated automatically at all.

[deviantintegral]

Both rebuilt a few minutes ago.

So, this can be solved by adding each tag as they are created to Docker Hub's list of tags, without regexes. I will do that now for all previous tags and update the README with a reminder.

[deviantintegral]

I added all existing tags and triggered builds a few hours ago, and they are still running. 0.0.6 actually build successfully, but then was "cancelled" right as the image was being pushed! Totally unimpressed with docker hub, but I've yet to find a free alternative that supports autobuilding on upstream changes like this.