v29.4-roots.1 · Commit 8: [PATCH 08/13] 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. Before is on the left; after is on the right. Unified view fits narrow screens more easily.
ci/README.md
CHANGED
|
@@ -49,30 +49,53 @@ env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j1" FILE_ENV="
|
|
| 49 |
The files starting with `0n` (`n` greater than 0) are the scripts that are run
|
| 50 |
in order.
|
| 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*.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 49 |
The files starting with `0n` (`n` greater than 0) are the scripts that are run
|
| 50 |
in order.
|
| 51 |
|
| 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.
|