Give images pushed by CI version numbers

[leighmcculloch]

What

Give images pushed by CI version numbers.

Each commit on the master branch that publishes to DockerHub will be given a version number with the number based on the number of commits on the master branch.

Each commit on a pull request branch that publishes will be given a version number also based on the number of commits.

E.g. for commit 300, the version number will be v300, and the labels for the commit published will be :v300-latest, :v300-testing, :v300-future.

For example, for PR 23, with commit number 200, the labels will be :pr23-v200-latest, etc.

The :latest, :testing, :future labels are also aliased to the version when published from master, and :pr-23-latest, etc when published from a pr.

Why

Make it easier to reference specific versions of the image.

At the moment folks have to dig up digests, which is fine, but it's much easier to be able to tell people "use v353 of the image."

The versioning isn't really necessary on PRs, but it was easier to make the master branch and PR branches work the same than it would be to make them work differently.

Implementation Details

The change involved moving the three image variant builds that run independently as their own workflows, under a single workflow that triggers them. This has some side-effects:

• All the builds are now viewable as a single workflow instead of independently, which makes it easier to watch a build in progress since three pages do not need to be opened in the browser.
• All the builds had to have their artifacts renamed to be unique within the larger single build, this will have no impact.
• Since there's a single "complete" build that github waits on, the auto merge feature of GitHub will be more reliable for this repo now, because before sometimes it would auto merge before all three image variants had completed if one or two had finished.

[leighmcculloch]

I'd like to rename the yml files so they more clearly communicate the intent, but to do so would make this diff much larger. So I'm leaving them as they are. The way the files are related is:

build-start.yml -> build-[latest|testing|future].yml -> build.yml

[leighmcculloch]

I placed the version number at the front of labels, i.e. v300-testing, but I think it'd also be reasonable to put it at the back such as testing-v300. Feedback appreciated.

[sreuland]

what do you think about generating version tags, but not on pr's or merge of master, rather generate version tags only on repo tag events and pull the gh tag name to use when publish the docker tag such as :<gh tag name>-latest and the gh tags could be done off a branch that locks in specific component versions in each image variant ci build, build-latest.yml, build-futur.yml, etc.

[leighmcculloch]

That's an option, and was approximately what I was suggesting here #530 (comment). But it would increase the maintenance burden on a repo that we try to be very minimal about. It'd also result in some variants probably falling behind on features than other variants.