You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
TODO
Await next icinga-kubernetes release
Look how well its GHA worked
Make the decision described above
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: