Replies: 3 comments
-
Thanks for the feedback. I agree that "sliding tags" is not particularly ergonomic. The team has a few things on their plate at the moment, but this is something that we'll take a look at in the not-too-distant future. |
Beta Was this translation helpful? Give feedback.
-
I think while tag parsing is certainly a feasible solution it also involves pulling and parsing the entire list of remote refs, which isn't always desirable. I would personally love to see first class support for Semantic Releases in GitHub itself, rather than kludging something onto GET /repos/{owner}/{repo}/releases/semver/{semver} I realize that's a lot more effort than just changing the Action runner to be able to do basic tag parsing, though. |
Beta Was this translation helpful? Give feedback.
-
Currently it appears that in order to support, for example, a reference to
me/myaction@v1
, I have to create a tag forv1
in my repository.This requirement creates a few problems:
v1
to refer to an actualv1.x.y
tag. i.e. it is possible forv1
to refer to something other than a validv1.x.y
tag;v1.2.3
but spot a problem, add a new commit, why not just re-tagv1.2.3
? This has led to many advising that commit shas be used as the version;v1
, or more generally,vN
orvN.M
tags;vN
tags refer to the latestvN.x.y
version (an order defined by the semver standard), and for those that don't a significant percentage should do but don't by virtue of avN
tag not having been updated.My proposal is therefore that action version resolution logic should be updated as follows:
vN
orvN.M
tag exists, use that tag;vN
should refer to the latest non-pre-release versionvN.x.y
;vN.M
should refer to the latest non-pre-release versionvN.M.x
.This proposal is backwards compatible with existing
vN
andvN.M
tags.Beta Was this translation helpful? Give feedback.
All reactions