v29.4-roots.3 · Commit 8: [PATCH 08/30] ci: restore assurance and isolate Core fixtures
ci/README.md
Before: ci/README.md · After: ci/README.md
File metadata
index a73c8df5e753a02dfd019d8edb92cc67ceb4fa52..b1dc991349ca11b5c40d35028833adb5bdc8f2fc 100644
Download original patch · Release notes
Diff rows 1–80 of 80. Line numbers refer to the original before/after files.
+ Added− RemovedUnmarked lines are context.
Scroll the code area horizontally to read long lines. The two line-number columns refer to before and after.
ci/README.md
CHANGED
|
@@ -49,30 +49,53 @@ env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j1" FILE_ENV="
|
|
|
49
49
|
The files starting with `0n` (`n` greater than 0) are the scripts that are run
|
|
50
50
|
in order.
|
|
51
51
|
|
|
52
|
-
## Cache
|
|
53
|
-
|
|
54
|
-
In order to avoid rebuilding all dependencies for each build, the binaries are
|
|
55
|
-
cached and reused when possible. Changes in the dependency-generator will
|
|
56
|
-
trigger cache-invalidation and rebuilds as necessary.
|
|
57
|
-
|
|
58
|
-
## Configuring a repository for CI
|
|
59
|
-
|
|
60
|
-
### Primary repository
|
|
61
|
-
|
|
62
|
-
To configure the primary repository, follow these steps:
|
|
63
|
-
|
|
64
|
-
1. Register with [WarpBuild](https://www.warpbuild.com/) and purchase runners.
|
|
65
|
-
2. Install the WarpBuild GitHub app against the GitHub organization.
|
|
66
|
-
3. Enable organisation-level runners to be used in public repositories:
|
|
67
|
-
1. `Org settings -> Actions -> Runner Groups -> Default -> Allow public repos`
|
|
68
|
-
4. Permit the following actions to run:
|
|
69
|
-
1. docker/setup-buildx-action@\*
|
|
70
|
-
1. actions/github-script@\*
|
|
71
|
-
|
|
72
|
-
### Forked repositories
|
|
73
|
-
|
|
74
|
-
When used in a fork the CI will run on GitHub's free hosted runners by default.
|
|
75
|
-
In this case, due to GitHub's 10GB-per-repo cache size limitations caches will be frequently evicted and missed, but the workflows will run (slowly).
|
|
76
|
-
|
|
77
|
-
It is also possible to use your own WarpBuild Runners in your own fork with an appropriate patch to the `REPO_USE_WARP_RUNNERS` variable in ../.github/workflows/ci.yml
|
|
78
|
-
NB that WarpBuild Runners only work at an organisation level, therefore in order to use your own WarpBuild Runners, *the fork must be within your own organisation*.
|
|
52
|
+
## GitHub Actions policy
|
|
53
|
+
|
|
54
|
+
Bitcoin Roots uses a smaller, risk-selected pull-request matrix rather than
|
|
55
|
+
running every Bitcoin Core CI configuration on every change:
|
|
56
|
+
|
|
57
|
+
| Workflow | Events | Purpose |
|
|
58
|
+
| --- | --- | --- |
|
|
59
|
+
| `.github/workflows/ci.yml` | pull request | Required lint plus path-selected build and test coverage. |
|
|
60
|
+
| `.github/workflows/nightly.yml` | schedule, manual dispatch, reusable call | Expensive sanitizer, fuzz, compatibility, and platform assurance. |
|
|
61
|
+
| `.github/workflows/release.yml` | Roots release tags, manual dispatch | Validate a canonical release tag and produce the five release packages and portable patch. |
|
|
62
|
+
|
|
63
|
+
These repository workflows are kept in every canonical Roots branch and release
|
|
64
|
+
tag so a PR tests the code it proposes. They are hosting automation, however,
|
|
65
|
+
so `ci/release/create-patch-series.sh` excludes `.github/**` from the
|
|
66
|
+
downloadable patch applied on top of Bitcoin Core. Source tests and CI support
|
|
67
|
+
under `test/**`, `src/**/test/**`, and `ci/**` remain in that patch.
|
|
68
|
+
|
|
69
|
+
### Pull-request selection
|
|
70
|
+
|
|
71
|
+
`ci/change-classifier.py` reads the complete PR file list using
|
|
72
|
+
`ci/change-classifier-policy.json`. Mixed changes receive the union of their
|
|
73
|
+
coverage. Incomplete, truncated, empty, ambiguous, and unknown inputs fail open
|
|
74
|
+
to broad coverage.
|
|
75
|
+
|
|
76
|
+
| Change | Automatic coverage in addition to lint |
|
|
77
|
+
| --- | --- |
|
|
78
|
+
| Documentation only | No build job. |
|
|
79
|
+
| Branding or GUI | GUI/resource build and Qt tests. |
|
|
80
|
+
| Wallet | Compatibility, sanitizers, fuzz, and platform smoke tests. |
|
|
81
|
+
| General C/C++ | Sanitizers, native Linux fuzz, ARM32, Windows, and both native macOS architectures. |
|
|
82
|
+
| Critical, build, CI, or unknown | Broad coverage, including GUI and previous-release compatibility. |
|
|
83
|
+
|
|
84
|
+
The stable `required result` job is the branch-protection check to require. It
|
|
85
|
+
fails if classification, lint, or any selected job fails.
|
|
86
|
+
|
|
87
|
+
Maintainers can add coverage with `ci:sanitizers`, `ci:fuzz`,
|
|
88
|
+
`ci:compat`, `ci:platforms`, or `ci:full` PR labels. Labels add tests;
|
|
89
|
+
they never suppress automatic coverage.
|
|
90
|
+
|
|
91
|
+
### Nightly assurance and caches
|
|
92
|
+
|
|
93
|
+
Nightly assurance retains TSan, MSan, clang-tidy/dependency checks, i686 Debug,
|
|
94
|
+
extended functional tests, previous-release compatibility, and native macOS
|
|
95
|
+
and Windows fuzz corpora. A scheduled run skips expensive jobs only after the
|
|
96
|
+
same commit has already completed successfully; failures retry and unavailable
|
|
97
|
+
history fails open.
|
|
98
|
+
|
|
99
|
+
GitHub-hosted compiler and dependency caches are read by PRs and updated only
|
|
100
|
+
from the repository's default branch. Cache misses make jobs slower but do not
|
|
101
|
+
change which tests run.
|