Add release workflow (GitHub Release on tag push)#15
Merged
Conversation
New `.github/workflows/release.yml` orchestrates the user-facing
release on `vX.Y.Z` tag push:
* Builds the four binaries fresh from the tagged commit.
* Assembles the .deb via `packaging/build-deb.sh` (dogfoods
deb-toolkit, same as the Package workflow).
* Verifies the produced .deb with `dpkg-deb --info` / `-c`.
* Creates a GitHub Release with auto-generated commit-summary
notes, plus an `Artifacts` / `Install` body explaining where the
Docker image lives and how to apt-install the .deb.
* Attaches the .deb as a release asset.
Scope is deliberately small for this first iteration:
* GitHub-side publishing only.
* Pushing to the production APT repositories
(`stable.apt.packages.minaprotocol.com` …) and signing the .deb
are out of scope — they need GPG keys + S3 credentials as repo
secrets and warrant their own PR.
* arm64 Docker / .deb is also a follow-up.
To avoid two workflows racing to attach the same asset to the same
release, the corresponding step in `package.yml` is removed (with a
comment pointing at this new file). The Package workflow remains
responsible for:
* GHCR push of the Docker image (on tag).
* Workflow-artifact upload of the .deb (always-on, for PR review).
Concurrency group `release-${ref}` keeps a re-pushed tag from racing
itself.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Appends an `apt install`-able publish step to the release workflow.
CLAUDE.md describes `packages.o1test.net` as the "for everything
multichannel repo" — unsigned legacy bucket, no GPG key required —
which is the right channel for the toolkit (internal CI tooling, no
end-user-facing security surface).
Steps added after the GitHub Release attach:
1. Set up Ruby 3.2 (deb-s3 is a Ruby gem).
2. `gem install deb-s3`.
3. `deb-s3 upload --bucket=packages.o1test.net --s3-region=us-west-2
--codename=bookworm --component=stable --preserve-versions <deb>`
Why deb-s3 directly rather than via release-manager: release-manager
is the right tool for the mina-daemon channel-promotion / fix /
verify flow, but this is a one-shot upload — the direct call is one
gem install + one command.
Required repo secrets (must be set on this repo before the next
tag push to a release):
* AWS_ACCESS_KEY_ID
* AWS_SECRET_ACCESS_KEY
Region (`us-west-2`) and bucket (`packages.o1test.net`) are stable
per CLAUDE.md and hardcoded.
Release notes body updated to lead with the apt one-liner now that
this exists, with the direct-`.deb` download kept as the fallback.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two coupled changes:
* Build the four release binaries with `--target
x86_64-unknown-linux-musl`. Static linking removes the glibc
floor entirely, so one .deb runs on bullseye (glibc 2.31) through
noble (2.39) without "version GLIBC_X.Y not found" surprises.
Possible because all four crates already use rustls (no OpenSSL
linkage to break under musl).
* Loop the upload across `bullseye focal jammy noble bookworm`.
Same .deb gets registered under each codename in
`packages.o1test.net`; deb-s3 happily handles the repeated
upload, and the underlying object in S3 is identical (just
referenced from five Packages indices).
To keep build-deb.sh from caring whether the binaries live under
`target/release/` or `target/<triple>/release/`, it now respects an
optional CARGO_TARGET env var that selects the subdir. Default
behaviour (no env var) is unchanged, so the package workflow keeps
working as-is — only release.yml opts into the musl path.
Release-notes body updated: the install snippet now leads with
"replace <CODENAME> with one of: bullseye focal jammy noble bookworm"
instead of pinning bookworm, and explicitly mentions the build is
musl-static so users understand why one .deb works everywhere.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Was originally stacked on #13 (now merged). Single new commit on top of main: `.github/workflows/release.yml` + a one-line tidy in `package.yml` removing the now-duplicate release-attach step.
Summary
New workflow that fires on `vX.Y.Z` tag push and produces a user-facing GitHub Release:
Workflow split
The duplicate "Attach to GitHub Release" step in `package.yml` is removed (with a pointing comment) so two workflows aren't racing to attach the same asset to the same Release.
Scope deliberately excluded (follow-ups)
Concurrency
`release-${ref}` group: re-pushing a tag cancels its previous in-flight run rather than racing.
Test plan
🤖 Generated with Claude Code