This wouldn't be a problem for X.Y.Z tags as they obviously don't concur with each other. X.Y ones are also not affected as we don't build e.g. 2.14.3 and 2.14.4 at the same time. Only latest is problematic. Sure, we already build all Docker tags mutually exclusive, so that e.g. 2.13.8 is not pushed to latest just after 2.14.0 if released at the same time.
But the 3rd party GHA icinga-kubernetes uses needs to know in advance whether to push latest and can't decide based on present tags in Docker Hub. I see these options:
Before tagging a new .0 of Icinga 2, we'd have to update the previous support branch and disable latest tagging there
The latter implies that it also happens before tagging on this support branch if such collides with the .0 (e.g. 2.13.8 & 2.14.0 released at the same time)
Disable latest tagging in that GHA completely for our case
Implication: we'd still need the mktags script for latest
This wouldn't be a problem for X.Y.Z tags as they obviously don't concur with each other. X.Y ones are also not affected as we don't build e.g. 2.14.3 and 2.14.4 at the same time. Only latest is problematic. Sure, we already build all Docker tags mutually exclusive, so that e.g. 2.13.8 is not pushed to latest just after 2.14.0 if released at the same time.
But the 3rd party GHA icinga-kubernetes uses needs to know in advance whether to push latest and can't decide based on present tags in Docker Hub. I see these options:
TODO