Great! However, it should be narrowed to tags only. Looking at the docs you linked I think something like this should be used

on:
  push:
    tags:
      - v*.*.*

But there's also the release event, which might be even better: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release

Great! However, it should be narrowed to tags only. Looking at the docs you linked I think something like this should be used

on:
  push:
    tags:
      - v*.*.*

This would prevent the workflow from running on pushes to main (after a PR is merged).
The push trigger also requires all conditions to be true. Combining a branch filter with a tag filter is not satusfyable.

I think the release event is triggered when publishing a release (not a tag).
The CICD workflow triggers the draft release so this is not possible either.

This would prevent the workflow from running on pushes to main (after a PR is merged).
The push trigger also requires all conditions to be true. Combining a branch filter with a tag filter is not satusfyable.

Maybe we can do:

on:
  push:
    tags:
      - v*.*.*
  push:
    branches:
      - main

I don't see any examples of that in the docs but also nothing that says that's not possible? This particular example might not be valid yaml, but something like it should be possible right?

I think the release event is triggered when publishing a release (not a tag).
The CICD workflow triggers the pre-release so this is not possible either.

I don't understand this part. Can't we just make a release that will trigger the CI?

This should be:

on:
  push:
    tags:
      - v*.*.*
    branches:
      - main

To support push on both branches and tags

Understanding the docs correctly is really hard. After reading them again, I agree with @piotrkwiecinski.

This is also shown in the example here: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-branches-and-tags

Adding two separate push triggers as suggested by @tertsdiepraam does not work, since this a JSON/YAML object and would result in duplicate keys.

Can't we just make a release that will trigger the CI?

Currently, the release engineer pushes the tag, that triggers the workflow, the workflow creates a draft release.
I'm not sure how the workflow should upload release artifacts if the release must already exist.

Understanding the docs correctly is really hard.

Yeah, they aren't great :(

Currently, the release engineer pushes the tag, that triggers the workflow, the workflow creates a draft release.
I'm not sure how the workflow should upload release artifacts if the release must already exist.

We have can create a release in the GitHub UI. I was thinking that could trigger the CI for and attach the artifacts to the release, but I'm happy with the current version if it works.

Thanks everyone :)