infra: reuse SIGNING_KEY for apt/rpm repo publishing#1483
Conversation
The apt/rpm publish workflows required separate REPO_SIGNING_KEY and REPO_SIGNING_KEY_ID secrets, but the repo already has a SIGNING_KEY (plus optional SIGNING_PASSWORD) used by the Maven Central release. Reuse them to avoid managing a second GPG key and to unblock the currently-failing apt-repo and rpm-repo workflows. The key id is now auto-detected from the imported keyring instead of being passed in as a secret, since a fresh GNUPGHOME contains only the one imported key. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis pull request consolidates GPG signing infrastructure across apt and rpm package repositories. Previously, each package type maintained separate 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@infra/apt/publish.sh`:
- Around line 96-97: The script currently picks the first secret key via the
gpg/awk pipeline (KEY_ID), which can silently pick the wrong key; change the
logic to enumerate secret keys with gpg --list-secret-keys --with-colons
--keyid-format=long, count the number of '^sec:' entries and if the count is not
exactly 1 print a clear error referencing SIGNING_KEY and exit non-zero,
otherwise extract that single key id and assign it to KEY_ID (keep reference to
the existing KEY_ID variable and the gpg/awk selection logic for the successful
path).
In `@infra/rpm/publish.sh`:
- Around line 76-77: The current extraction of KEY_ID from gpg output is brittle
when multiple secret keys exist; change the logic around the gpg
--list-secret-keys --with-colons --keyid-format=long pipeline to first count
matching "sec" entries and validate cardinality: if zero, fail with a clear
error; if >1, fail and ask the caller to specify which key via SIGNING_KEY
(fingerprint or keyid) rather than silently picking the first; if exactly one,
assign that key to KEY_ID. Use the same gpg listing invocation but add a
pre-check that filters by the provided SIGNING_KEY (if set) or enforces a single
matching sec entry before setting KEY_ID.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f557d241-2128-4c3d-8405-27e4882c220d
📒 Files selected for processing (5)
.github/workflows/apt-repo.yml.github/workflows/rpm-repo.ymlinfra/README.mdinfra/apt/publish.shinfra/rpm/publish.sh
Silently picking the first sec row from a multi-key payload would let the apt/rpm metadata be signed by the wrong key, which consumers would then fail to verify against the published archive keyring. Count the imported secrets and exit non-zero if it isn't exactly one. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
REPO_SIGNING_KEY/REPO_SIGNING_KEY_IDsecrets in the apt/rpm publish scripts and workflows with the existingSIGNING_KEY(and optionalSIGNING_PASSWORD) already used by the Maven Central release workflow.GNUPGHOMEonly ever holds the one imported key.infra/README.mdto reflect the shared key and drop the now-unnecessary step that minted a dedicated repo signing key.Why
The
apt-repo/rpm-repoworkflows were failing onmoq-dev/moqbecause none of theREPO_SIGNING_KEY*orR2_*secrets were ever configured (see the latest apt-repo run, which aborts onR2_ACCOUNT_ID: parameter null or not set). ReusingSIGNING_KEYremoves one secret to manage and keeps the GPG identity consistent across release surfaces.The R2 secrets still need to be added separately. After this PR lands, the only secrets required to unblock the workflows are
R2_ACCOUNT_ID,R2_ACCESS_KEY_ID, andR2_SECRET_ACCESS_KEY.Test plan
moq-dev/moq.gh workflow run apt-repo.yml --repo moq-dev/moq -f tag=<existing-deb-tag>and confirm the run signs the Release file and uploads toapt-moq-dev.rpm-repo.ymlagainst an existing rpm-bearing tag.(Written by Claude)
🤖 Generated with Claude Code