Skip to content

Build images like icinga-kubernetes (3rd party GHA, less own scripts) #130

Description

@Al2Klimov

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:

  1. Use the GHA like this in support branches ex. the latest support branch: https://github.com/renchap/mastodon/blob/3b9b4eda096e4c11ac4876d39e3bd71a4a1c5872/.github/workflows/build-image.yml#L52-L55
    • A maintainer confirmed you have to do it like this: Latest not linked to the highest version docker/metadata-action#80 (comment)
    • Implications:
      • 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)
  2. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions