push tag event to write semver tags isn't triggered because tags are pushed using GITHUB_TOKEN

[syaghoubi00]

I'm using a GITHUB_TOKEN to do my releases and tagging, but this prevents the push tag event from being triggered when the release workflow pushes the tags. Since the push tag event isn't triggered, I am unable to create the proper metadata semver tags, even though the tags exist in the repo.

I'd appreciate any ideas on how to work around this. I did try using a PAT which does trigger workflows - however this came with some undesirable effects, such as, all release/tagging 'bot' activities would be authored by me (via the PAT), be unverified, and key management becomes painful when having to roll a RELEASE_PAT across all repos.

Desired workflow:

1. Tags are pushed by github-actions[bot] using GITHUB_TOKEN
2. Build workflow is triggered, and the docker/metadata-action detects the push tag event and adds the semver tags to the metadata.

Current workflow:

1. Tags are pushed by github-actions[bot] using GITHUB_TOKEN
2. push tag event isn't triggered, so no metadata creation etc.

I know this is kind of a limitation with GH itself, with bots being unable to trigger other workflows, but I'd appreciate any ideas.

I was thinking about using a type=raw and parsing the tags from the repo and setting that to a variable, then passing that variable into the raw tag, like type=raw,${{ env.MAJOR_VER }}, but this seemed very hacky, and I'm not sure if it would even work.

[polarathene]

You can use the other types beyond raw, just provide the values to them via the value attribute explicitly.

Alternatively you could look at using a separate workflow trigger that might work, such as one that fires when a release has been published (which it sounds like your describing would trigger). I can't recall as I haven't looked up Github Actions docs in a while, so it might be prevented from triggering that, but I think some workflow triggers are compatible 🤔

Here's a fairly simple example workflow based on a release trigger, rather than a tag push event. That also includes a workflow_dispatch trigger for manually invoking.

There's a similar on.workflow_call trigger that you can use and have your workflow invoke as a subsequent job, that should work for you but you will need to provide it the relevant metadata/context (such as your expected tag to process, just use value attribute like the linked example shows).

You may want to be mindful of labels/annotations defaults if you also use those, in case any of those might not match what you might expect them to be.

• One example is the image version based on default priority attribute of each tag type, as yours would all be of raw the first enabled tag encountered would have it's tag output assigned as the image version (only relevant if you're using the image.version OCI label/annotation from this action).

---

I was thinking about using a type=raw and parsing the tags from the repo and setting that to a variable, then passing that variable into the raw tag, like type=raw,${{ env.MAJOR_VER }}, but this seemed very hacky, and I'm not sure if it would even work.

https://github.com/docker/metadata-action/#typeraw

That would work if you want to publish a tag manually.

The other tag types provide conveniences:

• Like type=semver implicitly sourcing it's value from the tag event and applying semver filters (for what tag inputs are valid, and how it's output value would be transformed, such as stripping away any v prefix).
• There are several tag types like type=semver that influence flavor.latest=auto to implicitly add a latest tag for publishing (which some users trip up with when they add a conditional raw equivalent).

For type=semver/type=pep440, these do have special logic for pre-release formatted tag values they receive. That logic can trip you up if you expect to have image tags with a v prefix to publish, but managing it all with type=raw means you'd need to manually implement the conditions for enable toggles yourself to avoid mistakenly having a pre-release tag update mutable tags that don't reflect a pre-release status (eg: for tag v1.2.3-alpha you would not want this to publish tags :1, :1.2, :1.2.3, only the pre-release tag :1.2.3-alpha), or you could still publish those via separate components you extract (like the env.MAJOR_VER you mention) and conditionally append the pre-lease component in value or via ,suffix=-alpha.

Additionally determining the latest release can sometimes be tricky / problematic, this action doesn't really help with that (see link for how you can approach that).

So for you it's really about balancing convenience of what you can comfortably delegate to the action, but implicit processing if you're not careful may cause surprises that aren't as clear to troubleshoot vs when you manually manage your tagging convention explicitly.