nexus/WifiPoolToMQTT
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Publish the version tag again on tag builds #6

Merged
nexus merged 1 commit from ci/version-tag into main 2026-07-23 14:29:28 +02:00
Conversation 0 Commits 1 Files changed 1 +34
nexus commented 2026-07-23 14:21:43 +02:00
Owner
Copy link

Splitting the push into one job per tag dropped the version tag. It is still
computed and compiled into the binary — wifipool-to-mqtt version shows it —
but no image tag is created from it any more, so a v1.2.3 release would have
published latest and the commit sha only. The README promises a version to
pin, and recommends pinning one in production.

A third job restores it. It is skipped unless the version differs from the
commit, which only a tag build produces, so on a normal push to main nothing
changes. It waits for publish-commit-tag instead of running beside it, so
there is never more than one push in flight — the constraint that made the
one-tag-per-job split necessary in the first place.

The mechanism is the same one publish-commit-tag already proves: a fresh job,
one login, one push. The only addition is a local docker tag, which costs no
push call. The version path itself is exercised the first time a v* tag is
pushed.

Splitting the push into one job per tag dropped the version tag. It is still computed and compiled into the binary — `wifipool-to-mqtt version` shows it — but no image tag is created from it any more, so a `v1.2.3` release would have published `latest` and the commit sha only. The README promises a version to pin, and recommends pinning one in production. A third job restores it. It is skipped unless the version differs from the commit, which only a tag build produces, so on a normal push to main nothing changes. It waits for `publish-commit-tag` instead of running beside it, so there is never more than one push in flight — the constraint that made the one-tag-per-job split necessary in the first place. The mechanism is the same one `publish-commit-tag` already proves: a fresh job, one login, one push. The only addition is a local `docker tag`, which costs no push call. The version path itself is exercised the first time a `v*` tag is pushed.
Publish the version tag again on tag builds
All checks were successful
CI / test (pull_request) Successful in 2m25s
Details
CI / test (push) Successful in 2m50s
Details
CI / image (pull_request) Successful in 58s
Details
CI / image (push) Successful in 53s
Details
CI / publish-commit-tag (pull_request) Has been skipped
Details
CI / publish-commit-tag (push) Has been skipped
Details
CI / publish-version-tag (pull_request) Has been skipped
Details
CI / publish-version-tag (push) Has been skipped
Details
3ec2839f44 
Splitting the push into one job per tag dropped the version tag: it was still
computed and compiled into the binary, but no image tag was created from it. A
release tag would therefore have published latest and the commit sha only,
while the README promises a version to pin.

A third job restores it, skipped unless the version differs from the commit,
which only a tag build produces. It waits for publish-commit-tag rather than
running beside it, so there is never more than one push in flight.
nexus merged commit 46bf937aae into main 2026-07-23 14:29:28 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nexus/WifiPoolToMQTT!6
No description provided.