Certain branches selected by regex not starting to build with automated builds

Docker Hub
1

I have set up a GitHub repository luzat/docker-httpd to build luzat/httpd. Branches such as release/2 and release/2.4 should automatically be built and tagged in Docker Hub.

For this purpose I created a number of rules (additional ones to support branches with release/1.2.3(+(foo.)123) syntax and tags with v1.2.3(+(foo.)123) syntax), but the following should apply to release/2 and release/2.4:

  • Type: Branch
  • Name: /^release\/([0-9]+)((\.[0-9]+)*)$/
  • Dockerfile: /
  • Docker Tag Name: {\1}{\2}

Unfortunately, only master (latest), release/2.4 (2.4) and tag v2.4.35 (2.4.35) were automatically built when pushing the repository and its tags. I can confirm on GitHub that release/2 has been successfully pushed, too. I tried deleting the branch and pushing again (git push origin -d release/2; git push -u origin release/2) without success. POST triggers do not work either:

curl -H "Content-Type: application/json" --data '{"source_type": "Branch", "source_name": "release/2"}' -X POST https://registry.hub.docker.com/u/luzat/httpd/trigger/secret-token-here/

returns an error page with not much more information than literally “Oops, there was an error! We have been contacted of this error, …”. The same curl command works fine for release/2.4 (which builds 2.4). The trigger logs do not show any error when no build happens (except if build throttle is the reason).

A similar rule (/^release\/(([0-9]+)(\.[0-9]+)*)$/, {\1}) does not work either. The following rule seems to work, but only if I delete the previously mentioned rules first:

  • Type: Branch
  • Name: release/2
  • Dockerfile: /
  • Docker Tag Name: 2

This is obviously not as flexible, but shows that release/2 can indeed be built.

I figure that there is some reason as to why both regex rules do not work for the short version (but do have the effect of making the static rule not working either; so, they seem to have some effect on branch matching). But what is it? It looks like a bug to me.

2

I found a working version with slightly different syntax: /^release\/([0-9.]+)$/, {\1}

This does give the expected results, even though it also allows invalid versions such as ... or 1..2. to get through. The previous regular expressions looked fine to me, but there may be problems or limitations with respect to how Docker Hub interprets them. I still consider this a bug, but maybe I am missing something here.