fix: extract mcvs-golang-action version from trailing comment - #453
Conversation
ergousha
left a comment
There was a problem hiding this comment.
Although we do not use such versioning in this repo given below, in order to comply with standard approach, consider the comment below. By this way, this block will be re-usable without hassle.
The regex ^[[:space:]](v?[0-9]+(.[0-9]+))[[:space:]]*$ strictly matches numeric version structures (e.g., v1, v1.2.3). If a pre-release or release-candidate version tag is used (e.g., v3.12.1-rc.1, v3.12.1-beta.2), the regex will reject the line comment and trigger the fallback to the commit SHA, reporting a false-positive mismatch.
Suggested Refinement:
Supports versions like v1.2.3, 1.2.3-rc.1, v2.0.0-beta+exp.sha.5114f85
expected_mcvs_golang_action_version=$(yq "${mcvs_golang_action_uses} | line_comment" .github/workflows/golang.yml | sed -nE 's/^[[:space:]](v?[0-9]+(.[0-9]+)(-[0-9A-Za-z.-]+)?(+[0-9A-Za-z.-]+)?)[[:space:]]*$/\1/p')
When the action is pinned to a commit sha, the readable version lives in the trailing comment: uses: 9be40cef... # v3.12.1 yq strips that comment when selecting the `uses` scalar, so the sync check compared the sha against REMOTE_URL_REF and always reported a mismatch. Read the version from `line_comment` first and fall back to the ref after `@` when the action is not sha pinned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The comment pattern only matched plain numeric versions, so a pre-release or release-candidate tag such as v3.12.1-rc.1 or v2.0.0-beta+exp.sha.5114f85 was rejected. That fell back to the commit sha and reported a false-positive mismatch against REMOTE_URL_REF. Extend the pattern with the optional semver pre-release and build metadata segments. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
635ee7f to
81b95ea
Compare
When the action is pinned to a commit sha, the readable version lives in the trailing comment:
uses: 9be40cef... # v3.12.1
yq strips that comment when selecting the
usesscalar, so the sync check compared the sha against REMOTE_URL_REF and always reported a mismatch. Read the version fromline_commentfirst and fall back to the ref after@when the action is not sha pinned.