publish-release in .github/workflows/release.yml strictly validates the tag format at its Verify tag step:
if [[ ! "${TAG}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
echo "Invalid tag format: ${TAG}. Expected v<major>.<minor>.<patch>" >&2
exit 1
fi
publish-npm has no such check. It strips the v prefix and proceeds:
Since the two jobs are independent (no needs: edge), a malformed tag dispatch (e.g., gh workflow run release.yml -f tag=v1.0-rc1) would fail publish-release's Verify tag step, but publish-npm would still attempt to run with a potentially invalid version comparison.
Options
- Add the same regex check to publish-npm's Verify-versions step as a precondition.
- Make publish-npm depend on publish-release via
needs: [publish-release] so tag validation gates both.
Low-risk today (operator-triggered only), but the ergonomic inconsistency is worth closing. Mild preference for (1) since one job failing shouldn't block the other — keeps jobs independent.
Originally flagged by CodeBeast review of #118.
publish-releasein.github/workflows/release.ymlstrictly validates the tag format at itsVerify tagstep:publish-npmhas no such check. It strips thevprefix and proceeds:EXPECTED="${TAG#v}"Since the two jobs are independent (no
needs:edge), a malformed tag dispatch (e.g.,gh workflow run release.yml -f tag=v1.0-rc1) would fail publish-release'sVerify tagstep, but publish-npm would still attempt to run with a potentially invalid version comparison.Options
needs: [publish-release]so tag validation gates both.Low-risk today (operator-triggered only), but the ergonomic inconsistency is worth closing. Mild preference for (1) since one job failing shouldn't block the other — keeps jobs independent.
Originally flagged by CodeBeast review of #118.