doc: Ensure that you can build release *before* pushing tags.
What the developer wrote
Authored by Rusty Russell
doc: Ensure that you can build release *before* pushing tags.
We found a bug last release, and had to yoink tag back from GH. This is not good!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit only changes the order of steps in a release checklist document. It moves the local build-and-sign steps before pushing the release tag to GitHub, so a broken release is caught before a public tag is created. There is no code change and no security vulnerability is being fixed.
No security action required; treat as normal documentation/process improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff updates doc/contribute-to-core-lightning/release-checklist.md to reorder the release workflow: confirm git describe, run cl-repro.sh, run build-release.sh sign, then push the tag, then compare artifacts. This is a process/documentation hardening measure to avoid retracting published tags; it does not modify source code, build scripts, cryptographic logic, or CI behavior.
Changed components
doc/contribute-to-core-lightning/release-checklist.mdInspect captured patch +6 / −5
diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md
index 6d1a545a..db411a7b 100644
--- a/doc/contribute-to-core-lightning/release-checklist.md
+++ b/doc/contribute-to-core-lightning/release-checklist.md
@@ -31,11 +31,12 @@ Here's a checklist for the release process.
1. Merge the above PR.
2. Tag it `git pull && git tag -s v<VERSION>rc1`. Note that you should get a prompt to give this tag a 'message'. Make sure you fill this in.
-3. Confirm that the tag will show up for builds with `git describe`
-4. Push the tag to remote `git push --tags` (pushing the tag will kickoff the "Release 🚀" CI action which builds the release targets and a draft release).
-7. Run the script `contrib/cl-repro.sh` for [Builder image setup](https://docs.corelightning.org/docs/repro#builder-image-setup). This will create the required builder images `cl-repro-<codename>` for the next step.
-8. Sign the release locally by running `tools/build-release.sh sign` which will sign the release contents and create SHA256SUMS and SHA256SUMS.asc in the release folder. Compare these with `c-lightning-<release tag>`.zip on GitHub.
-9. Check the generated draft `v<VERSION>rc1` release on Github and check `Set as a pre-release` option. Add the SHA256SUMS.asc from your local release folder to newly drafted release, replacing it.
+3. Confirm that the tag will show up for builds with `git describe`. We don't push it to GitHub yet, just in case the following steps fail, and more fixes are required!
+4. Run the script `contrib/cl-repro.sh` for [Builder image setup](https://docs.corelightning.org/docs/repro#builder-image-setup). This will create the required builder images `cl-repro-<codename>` for the next step.
+5. Sign the release locally by running `tools/build-release.sh sign` which will sign the release contents and create SHA256SUMS and SHA256SUMS.asc in the release folder.
+6. Push the tag to remote `git push --tags` (pushing the tag will kickoff the "Release 🚀" CI action which builds the release targets and a draft release).
+7. Compare your release/`c-lightning-<release tag>`.zip on GitHub.
+8. Check the generated draft `v<VERSION>rc1` release on Github and check `Set as a pre-release` option. Add the SHA256SUMS.asc from your local release folder to newly drafted release, replacing it.
9. Announce rc1 release on core-lightning's release-chat channel on Discord & [BuildOnL2](https://community.corelightning.org/c/general-questions/).
10. Use `devtools/credit --verbose v<PREVIOUS-VERSION>` to get commits, days and contributors data for release note.
11. Prepare release notes draft including information from above step, and share with the team for editing.
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.