Esa Kataja
2a148aa2a8
A release reported success while uploading the previous one a second time. Three separate faults, one of which hid the others. release declared image and push as prerequisites. Make runs targets in parallel by default here (-j16), so push resolved a tag and uploaded :latest before image had finished building and tagging. They are sub-makes now, as check already was. push re-derived the tag with `git tag --sort=-creatordate | head -1`. That is ambiguous when two tags point at the same commit, so it could pick the wrong one even without a race — and re-deriving is what made the race possible at all. image now records what it built in .release-tag and push reads it. Nothing compared what was built against what arrived, so the failure was silent: the build log said "Successfully tagged v...-3" while the registry received the older image. push now pulls each tag back afterwards and compares image ids, failing if the registry serves something else. The tag ambiguity surfaced because a test of the failure path did not fail. That was worth more than the fix it was checking.
18 lines
321 B
Plaintext
18 lines
321 B
Plaintext
# Local config — holds the registry hostname and the shared password.
|
|
.env
|
|
|
|
# Build output
|
|
/foodster
|
|
|
|
# The tag `make image` last built, handed to `make push`.
|
|
/.release-tag
|
|
|
|
# Generated by `templ generate` during the container build.
|
|
*_templ.go
|
|
|
|
# The database and its SQLite companions.
|
|
/data/
|
|
*.db
|
|
*.db-shm
|
|
*.db-wal
|