ci: skip an existing X.Y.Z-rN built from the same Pin, whichever run comes first #33
No reviewers
Labels
No labels
bug
enhancement
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
vicoli-oss/docker-forgejo-mcp!33
Loading…
Reference in a new issue
No description provided.
Delete branch "piscis/forgejo-7-same-pin-skip"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #7
Summary
When
X.Y.Z-rNalready exists,scripts/publish.shnow compares this run's Pin with the Pin the existing Image was built from. It no longer compares with the commit before the push, so the result doesn't depend on which run goes first.ci.yml, andpublish.shtakes 3 arguments instead of 4.REBUILDwith a staleREBUILD_OFstill fails, because its Pin differs from the one the existing tag was built from.3.2.0-r1hasrevision=7f2e214(the merge of #28), and its Pin matchesmain. So the next push tomainskips it and stays green. I checked this locally against the real registry.Evidence
I ran the real workflow on a throwaway branch that published to a test package (both are deleted now):
REBUILD=2,REBUILD_OFstale, which still resolves to 3.2.0-r1Merge Danger
Door: two-way
The change only affects what happens when a tag already exists. It never pushes where the old rule wouldn't have.
Blast Radius: CI
A tag whose Pin can't be read fails instead of being skipped, for example if its revision was on a branch that has since been deleted. Every tag published from
mainso far has a readable revision.