v30.3-roots.1 · Commit 66: [PATCH 66/68] fix(release): validate notices and reuse proven promotion CI
contrib/roots/README.md
Before: contrib/roots/README.md · After: contrib/roots/README.md
File metadata
index ed09fa141e22280b0a53b9f19cc69fcb9e7fd959..18553e5d69d5dc481f31305418f8d10a847ba097 100644
Download original patch · Release notes
Diff rows 1–63 of 63. Line numbers refer to the original before/after files.
+ Added− RemovedUnmarked lines are context.
Scroll the code area horizontally to read long lines. Before is on the left; after is on the right. Unified view fits narrow screens more easily.
contrib/roots/README.md
CHANGED
|
@@ -211,20 +211,44 @@ git push --force-with-lease origin HEAD:<branch>
|
|
| 211 |
|
| 212 |
Never force-push release tags. Preserve archival branches.
|
| 213 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 214 |
## Release handoff
|
| 215 |
|
| 216 |
Release tags use the Roots form `v<core-version>-roots.<positive-integer>`;
|
| 217 |
release candidates may use `v<core-version>rc<n>-roots.<positive-integer>`.
|
| 218 |
Before creating a permanent tag, merge the reviewed promotion so the trusted
|
| 219 |
-
workflow is present on the default branch. Then dispatch `Release artifacts`
|
| 220 |
-
with the future tag name and the full 40-hex canonical commit. Manual dispatch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 221 |
fetches the official Core tag from the Bitcoin Core repository, verifies the
|
| 222 |
commit against `origin/roots/<core-version>`, creates an annotated tag only in
|
| 223 |
each disposable runner checkout, and builds the same five-platform artifact
|
| 224 |
set. It has read-only repository permissions and cannot create a GitHub
|
| 225 |
release. It also refuses to run if the future tag already exists remotely.
|
| 226 |
|
| 227 |
-
For example:
|
| 228 |
|
| 229 |
```sh
|
| 230 |
release_tag=v30.3-roots.1
|
|
@@ -233,9 +257,13 @@ gh workflow run release.yml --ref main \
|
|
| 233 |
-f release_tag="$release_tag" -f release_commit="$release_commit"
|
| 234 |
```
|
| 235 |
|
| 236 |
-
Download and inspect that run's five packages and patch artifact before
|
| 237 |
-
assigning the permanent version. After the rehearsal passes, fetch again and
|
| 238 |
-
verify the annotated tag target and ancestry immediately before pushing it:
|
|
|
|
|
|
|
|
|
|
|
|
|
| 239 |
|
| 240 |
```sh
|
| 241 |
release_tag=v30.3-roots.1
|
|
|
|
| 211 |
|
| 212 |
Never force-push release tags. Preserve archival branches.
|
| 213 |
|
| 214 |
+
## Reusing canonical CI for a pure main promotion
|
| 215 |
+
|
| 216 |
+
Run ordinary fix CI, review it and integrate the canonical topic by fast-forward
|
| 217 |
+
before opening/updating its main promotion PR. Preserve a two-parent promotion
|
| 218 |
+
with current main first and the exact current canonical tip second.
|
| 219 |
+
`verify-promotion-ci.py` checks blob/mode/symlink parity outside the reviewed
|
| 220 |
+
main-only website/guidance/lint exceptions; CI and release workflows are never
|
| 221 |
+
exceptions. It requires the latest complete successful PR Tests run at the exact
|
| 222 |
+
candidate, in this repository, targeting its canonical branch, with successful
|
| 223 |
+
classifier, lint and required-result jobs. Claimed promotion proof mismatches
|
| 224 |
+
fail; they do not waive tests. Ordinary PRs retain normal CI.
|
| 225 |
+
|
| 226 |
+
A proven promotion reuses compiled-test results, while its classifier/regression
|
| 227 |
+
suite, lint and applicable independent main docs/site checks still run. Explicit
|
| 228 |
+
`ci:full` or other `ci:*` coverage labels keep requested fresh tests. Open the
|
| 229 |
+
promotion after source CI passes so no duplicate matrix is scheduled while
|
| 230 |
+
candidate evidence is incomplete. Optional checks do not claim reproducible
|
| 231 |
+
binaries, and existing release tags cannot be manually rehearsed.
|
| 232 |
+
|
| 233 |
## Release handoff
|
| 234 |
|
| 235 |
Release tags use the Roots form `v<core-version>-roots.<positive-integer>`;
|
| 236 |
release candidates may use `v<core-version>rc<n>-roots.<positive-integer>`.
|
| 237 |
Before creating a permanent tag, merge the reviewed promotion so the trusted
|
| 238 |
+
workflow is present on the default branch. The default path tags the reviewed
|
| 239 |
+
canonical source once; the tag runs fresh five-platform builds, required
|
| 240 |
+
manifest signing and new-draft creation. Independently verify that draft before
|
| 241 |
+
separate publication approval.
|
| 242 |
+
|
| 243 |
+
An optional `Release artifacts` manual dispatch rehearses an absent future tag
|
| 244 |
+
at the full 40-hex canonical commit. Manual dispatch
|
| 245 |
fetches the official Core tag from the Bitcoin Core repository, verifies the
|
| 246 |
commit against `origin/roots/<core-version>`, creates an annotated tag only in
|
| 247 |
each disposable runner checkout, and builds the same five-platform artifact
|
| 248 |
set. It has read-only repository permissions and cannot create a GitHub
|
| 249 |
release. It also refuses to run if the future tag already exists remotely.
|
| 250 |
|
| 251 |
+
For an explicitly requested optional rehearsal:
|
| 252 |
|
| 253 |
```sh
|
| 254 |
release_tag=v30.3-roots.1
|
|
|
|
| 257 |
-f release_tag="$release_tag" -f release_commit="$release_commit"
|
| 258 |
```
|
| 259 |
|
| 260 |
+
When requested, download and inspect the optional rehearsal's packages and
|
| 261 |
+
patch. It does not replace the final tag run or establish binary reproducibility.
|
| 262 |
+
Corrections renew source review, required CI and affected final-build verification.
|
| 263 |
+
An optional rehearsal remains optional; repeat it only when explicitly requested.
|
| 264 |
+
A failed final build requires diagnosis and renewed affected verification.
|
| 265 |
+
Fetch again and verify the annotated tag target and ancestry
|
| 266 |
+
immediately before pushing:
|
| 267 |
|
| 268 |
```sh
|
| 269 |
release_tag=v30.3-roots.1
|