Build all branches, delete image versions when branches/tags are deleted

[nwiltsie]

Description

This is a major overhaul of this Action, intended to be released as v2.0.0 (see plan from #12). The gist of these changes is that the Action manages the full lifecycle of images in GHCR: it will now build and deploy images for all branches of the repository, as well as all SemVer tags. When a branch or tag is deleted from GitHub, the corresponding image version is deleted from the container registry. (That is #13, but I'm not going to close that issue until the refactor-base branch is merged back into main).

The git SemVer tag v1.2.3 will result in the docker version 1.2.3 (note the lack of v).

The git branch foobar will result in the docker version branch-foobar. The one exception to this behavior is that the main branch will map to dev - that's in line with the current behavior of this Action.

[!NOTE]
The default branch name is hard-coded as main. docker/metadata-action has an {{is_default_branch}} expression, but unfortunately there is currently no way to negate it.

Testing

I tested this Action with a fresh repository - the assorted runs can be seen here. The example workflow in the README sets the run-name to a useful value:

Individual workflow runs will emit annotations linking to the newly-created or deleted image versions:

Errata

• The image deletion logic only works for GHCR, so our default usage of is now a required usage. I replaced the registry input (default ghcr.io/uclahs-cds) with an organization input (defaults to the organization of the calling repository, usually uclahs-cds for us).
• The run-name for tags (e.g. "Update v0.0.8 docker tag") incorrectly includes the leading v. GitHub Expressions don't have a substring function, and I couldn't figure out any way to abuse the existing functions to replicate it.

Checklist

• [x] This PR does NOT contain PHI or germline genetic data. A repo may need to be deleted if such data is uploaded. Disclosing PHI is a major problem.
• [x] This PR does NOT contain molecular files, compressed files, output files such as images (e.g. .png, .jpeg), .pdf, .RData, .xlsx, .doc, .ppt, or other non-plain-text files. To automatically exclude such files using a .gitignore file, see here for example.
• [x] I have read the code review guidelines and the code review best practice on GitHub check-list.
• [x] I have set up or verified the main branch protection rule following the github standards before opening this pull request.
• [x] The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].
• [x] I have added the major changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

[yashpatel6]

I'll get to this in the next couple of days!

[aholmes]

thought (non-blocking):

The git branch foobar will result in the docker version branch-foobar. The one exception to this behavior is that the main branch will map to dev - that's in line with the current behavior of this Action.

Cool - though not directly relevant to this PR, dev also fits the Python version specifier format which can make this flow nicely with related PyPI packages.

note (non-blocking):

Note

The default branch name is hard-coded as main. docker/metadata-action has an {{is_default_branch}} expression, but unfortunately there is currently no way to negate it.

I didn't check to see if you're doing something to get around this, but here's a suggestion. In BL_Python there are several outputs from jobs that are used in later jobs. For example, here's how I create the cache key in the initial checkout that is then referenced by all subsequent jobs. You can similarly negate the value of is_default_branch in a script and output that value for later use.

[aholmes]

question (non-blocking):

The one exception to this behavior is that the main branch will map to dev

Though we have typically avoided using it, thoughts on updating the latest tag (in addition?) ?

[nwiltsie]

You can similarly negate the value of is_default_branch in a script and output that value for later use.

Unfortunately it's not a variable is_default_branch, it's a Handlebars template {{is_default_branch}} that is only evaluated within the docker tags action, so I don't think it can be cached anywhere. The logic isn't too complicated but it felt like too much to replicate for this PR.

Though we have typically avoided using it, thoughts on updating the latest tag (in addition?) ?

I don't think we shouldn't have both dev and latest pointing to the same version. Given that, and assuming we keep dev, I guess latest would point to the highest official release? I don't like latest in general for exactly this ambiguity, but I'm open to the discussion.

[aholmes]

Though we have typically avoided using it, thoughts on updating the latest tag (in addition?) ?

I don't think we shouldn't have both dev and latest pointing to the same version. Given that, and assuming we keep dev, I guess latest would point to the highest official release? I don't like latest in general for exactly this ambiguity, but I'm open to the discussion.

I share your concern, and see the utility in latest. However, given that we have typically avoided its use, and coming SOPs are stricter about dependencies, we should probably continue to not use latest.