We recommend creating releases using semantically versioned tags – for example, v1.1.3 – and keeping major (v1) and minor (v1.1) tags current to the latest appropriate commit.
Following this pattern allows consumers of the action to specify a major version, allowing automatic updates for any bug fixes or new features. I was using v3, but all of my builds broke when the go 1.17 update happened in the aquasecurity repo, even after v3.0.1 was released. For consumers who wish to tightly control the versions of actions, they are able to continue to pin their desired version down to the patch level. This is fairly standard practice among the most popular GitHub Actions, including https://github.com/actions/checkout
Additional details: as written here, this workflow will trigger automatically whenever a new release is created manually, since that is the method you mentioned is currently in use. Tested with regular manual releases, pre-releases, and draft releases that are then published
Fixes #49
I noticed the
v3tag in this repo, but it does not actually represent the latest minor/patch version within the major version as the tag would imply.From the releasing-and-maintaining-actions docs:
Following this pattern allows consumers of the action to specify a major version, allowing automatic updates for any bug fixes or new features. I was using
v3, but all of my builds broke when the go 1.17 update happened in the aquasecurity repo, even afterv3.0.1was released. For consumers who wish to tightly control the versions of actions, they are able to continue to pin their desired version down to the patch level. This is fairly standard practice among the most popular GitHub Actions, including https://github.com/actions/checkoutAdditional details: as written here, this workflow will trigger automatically whenever a new release is created manually, since that is the method you mentioned is currently in use. Tested with regular manual releases, pre-releases, and draft releases that are then published