airvzxf / airvzxf/ftp-deployment-action
fix(release): concurrency: release-<tag> is not applied to the push phase of a re-pushed tag
- Dominant language
- Shell
- Stars
- 37
- Forks
- 9
- Avg merge
- 44m
- Merged PRs (30d)
- 47
Description
gh issue create --title "fix(release): concurrency: release- is not applied to the push phase of a re-pushed tag" --label "bug,audit,priority:high" --body "## Finding
release.yml has `concurrency: release-` to serialize releases on the same tag. The concurrency group key is `release-\${{ github.event.release.tag_name }}`. On a re-pushed tag (the same tag SHA is updated, e.g. when a tag is force-pushed after a failed build), the concurrency group is the same. But the concurrency check is on `github.event.release.tag_name` only, not on the SHA. Two releases of the same tag with different SHAs can race.
This is rare (tag rewriting is not the normal flow) but it bypasses the serialize-by-tag intent.
## Affected code
- .github/workflows/release.yml — concurrency block
## Reproduction
1. Push tag v2.11.3.
2. While the first build runs, force-push the same tag to a different commit (after deleting the tag locally + re-creating).
3. Observe: both runs execute in parallel; the second one wins on the registry.
## Suggested fix
Either:
- Document that tag rewriting is forbidden (treat it as a security event).
- Or include the SHA in the concurrency key: `release-\${{ github.event.release.tag_name }}-\${{ github.sha }}`.
The first option is preferred because tag rewriting is already discouraged by AGENTS.md.
## Source
F2 audit 2026-09-03 (workflows audit). Reporter: subagent-pekodbj7.
## Related
- Part of EPIC #[epic-number]
- Closes: #NONE (no existing issue)"
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.