CD: GitHub Actions workflow, publish all releases

[adamjstewart]

Summary

The previous trigger published all tags starting with a v, which includes very-bad-idea and excludes 1.0.0. The new trigger publishes all releases made through GitHub. Note that some projects do not include a v in their tags, but some projects also don't publish releases, only tags.

Test Plan

I've been using this workflow for years. Documentation can be found here: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#release

[konstin]

The current recommendation is a common pattern where you can kick off a release from the CLI with git tag v1.2.3 && git push --tags. A GitHub release as starting point would be a very different, more complex workflow; I'd rather keep the recommendation in our docs with the most popular, easy to understand flow.

[adamjstewart]

I guess my experience has been that non-v tags are more common than non-released tags, but don't have statistics to back this up. Completely fine with closing if that's your preference.

[woodruffw]

+1 @konstin, IMO there are different (good!) reasons to use either pattern but in practice tag-originated release flows have some advantages in terms of the flow of state (allowing a full release process to complete before the GitHub release itself is created/mutated in a visible way).

I think we could tighten the tag pattern, though -- maybe we could suggest v*.*.*, since that'll match version-shaped tags?

[zanieb]

Personally, I do

on:
  push:
    tags:
      - "[0-9]+.[0-9]+.[0-9]+"
      - "[0-9]+.[0-9]+.[0-9]+rc[0-9]+"
      - "[0-9]+.[0-9]+.[0-9]+[ab][0-9]+"

In my projects which use tag-triggered releases

[zanieb]

(I think we can / should do better than "*" that drives me crazy)