ci: attach the static binaries to the release - #692
Merged
Conversation
Pushing a v* tag already builds the static binaries for all five architectures, but they are left as workflow artifacts: cutting a release means downloading five of them by hand and uploading them again, which is how conmon.amd64 & co. ended up on v2.2.1. Do it in the workflow instead. If no release exists for the tag yet -- a tag pushed on its own, rather than one created along with a release from the web UI -- create a draft one, so that the release notes can be written before anything is announced: publishing the release is what triggers packit's downstream sync to Fedora and CentOS Stream. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jnovy
approved these changes
Aug 26, 2026
jnovy
left a comment
jnovy
left a comment
Collaborator
There was a problem hiding this comment.
LGTM. Clean, well-motivated CI improvement. Good security posture (scoped permissions, pinned actions), correct handling of the merge-gate job dependency, thoughtful draft-vs-published distinction for packit, and idempotent re-run behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pushing a
v*tag already builds the static binaries for all five architectures, but they are left as workflow artifacts: cutting a release means downloading five of them by hand and uploading them again, which is howconmon.amd64& co. ended up on v2.2.1. Do it in the workflow instead.If no release exists for the tag yet — a tag pushed on its own, rather than one created along with a release from the web UI — the job creates a draft, so that the release notes can be written before anything is announced. Publishing the release is what triggers packit's downstream sync to Fedora and CentOS Stream, so it matters that the workflow does not publish anything by itself.
Testing
The
uploadjob only runs on av*tag, so a PR run does not exercise it at all. It was tested by pushing a scratch tag to my fork, with the cachix push dropped for that run since a fork has noCACHIX_AUTH_TOKEN(reading from the cache still works). The tag, the branch and the draft release have since been deleted.The draft was created, the five assets were attached under the same names v2.2.1 uses, and the downloaded
conmon.amd64is a stripped, statically linked ELF that runs and reports its version.