Repository navigation
Conversation
3 tasks done
PastaPastaPasta
added a commit
to dashpay/dash
that referenced
this pull request
Oct 27, 2026
289c7f8 ci: bake the macOS SDK into the CI runner image (Konstantin Akimov) 4d3394a ci: stop bundling the test binaries that the test job deletes on arrival (Konstantin Akimov) bb9e9af ci: compress functional test logs with zstd level 9 (Konstantin Akimov) 494531f ci: write ccache entries at zstd level 9 instead of recompressing later (Konstantin Akimov) f6a7aee ci: upload guix outputs without recompressing them (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented A develop run uploads about 4.1 GB of artifacts and the repository cache sits at 7.9 GB of its 10 GB limit (run https://github.com/dashpay/dash/actions/runs/39637558287). Much of that is data nobody reads: - Every build bundle carries test_dash, bench_dash, fuzz, test_dash-qt and the generated qrc_*.cpp sources. The functional test job deletes them right after extracting the bundle (ci/dash/slim-workspace.sh), and in a local build they are about two thirds of the bundled binaries. - Functional test logs are compressed at zstd level 5. They are repetitive text where higher levels are nearly free. - ccache entries are written at level 1 and then every build, including pull request builds that never save the cache, recompresses the whole cache with `ccache -X 9`. The remote ccache only ever receives the level 1 bytes. - The guix workflow uploads .tar.gz, .zip and .dmg outputs through upload-artifact's default zip compression. - The macOS SDK took nine workflow steps, a workflow input/output pair and a slot in the repository cache for a 200 MB input that only changes with the Xcode version. ## What was done? One commit per item: - `ci: bake the macOS SDK into the CI runner image`: download, verify and extract the SDK while building ci.Dockerfile, the way bitcoin#27028 does, and point depends at it through SDK_PATH. Removes the cache lookup, download, artifact handoff and restore steps from build-depends.yml and build-src.yml. - `ci: stop bundling the test binaries that the test job deletes on arrival`: bundle-artifacts.sh excludes the test binaries and generated qrc sources, and slim-workspace.sh no longer lists them. dash-qt and dash-tx stay in the bundle because the win64 and mac bundles have no test job and exist for people to download product binaries. - `ci: compress functional test logs with zstd level 9`: on a 160 MB log sample level 9 is 13% smaller than level 5 at 0.3 s instead of 0.2 s. Level 19 would be 32% smaller but over a hundred times slower, which does not scale to the multi-gigabyte sanitizer logs. - `ci: write ccache entries at zstd level 9 instead of recompressing later`: CCACHE_COMPRESSLEVEL=9 in ci/test/00_setup_env.sh and the `ccache -X 9` pass dropped from build-src.yml. On 1 GB of object files level 9 is 7% smaller than level 1; level 5 gains nothing over level 1. - `ci: upload guix outputs without recompressing them`: compression-level 0 on the guix artifact upload. ## How Has This Been Tested? Note that pull_request_target runs the workflow YAML from develop, the removal of the SDK workflow steps, the removal of `ccache -X 9` from build-src.yml had been tested by PR in the fork: knst#11 CI run of this PR: https://github.com/dashpay/dash/actions/runs/40204419499 (all jobs green), compared against the develop run https://github.com/dashpay/dash/actions/runs/39637558287. This PR reduces artifact volume by 38 percent and simplifies the mac SDK handling; it does not change billed minutes. ### Artifact sizes, develop vs this PR: | artifact | develop | PR | change | |---|---|---|---| | build-linux64 | 313 MB | 129 MB | -59% | | build-linux64_asan | 421 MB | 181 MB | -57% | | build-linux64_tsan | 423 MB | 237 MB | -44% | | build-linux64_sqlite | 316 MB | 141 MB | -55% | | build-linux64_nowallet | 277 MB | 127 MB | -54% | | build-linux64_multiprocess | 258 MB | 158 MB | -39% | | build-aarch64-linux | 286 MB | 117 MB | -59% | | build-mac | 171 MB | 113 MB | -34% | | build-win64 | 378 MB | 372 MB | -2% (keeps dash-qt) | | build-linux64_fuzz | 76 MB | 17 MB | -77% | | test_logs-linux64 | 264 MB | 216 MB | -18% | | test_logs-linux64_asan | 274 MB | 221 MB | -19% | | test_logs-linux64_tsan | 345 MB | 282 MB | -18% | | test_logs-linux64_sqlite | 238 MB | 195 MB | -18% | | test_logs-linux64_nowallet | 79 MB | 66 MB | -17% | ### Step timings, baseline vs the two warm runs - Bundle artifacts: 7-8 s to 3-5 s on the asan and sqlite builds, 2-3 s elsewhere. - Download build artifacts: nowallet 13 s to 6 s, tsan 9 s to 5 s, multiprocess 8 s to 3-7 s. - Bundle test logs: 3-5 s more for the higher zstd level (linux64 21 s to 23-26 s, tsan 10 s to 15 s). - mac-build and the depends check-cache jobs no longer have the SDK restore/prepare/upload steps (4 s in the baseline mac job). The mac depends and mac build jobs built against the SDK baked into the image: the image sets SDK_PATH and depends/Makefile only defaults it when unset. The mac job went from 5.3 min to 4.1 and 3.6 min; most of that is a 44 s ccache restore in the baseline against 1-2 s here. - Save ccache cache ran on all 11 targets of the develop run; the saved entries are 128-203 MB each, one full build at level 9, against 556-577 MB on dashpay. ## Breaking Changes None for users. The build-* artifacts no longer contain test_dash, bench_dash, fuzz or test_dash-qt; anyone who downloaded those from CI must build them locally. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone Top commit has no ACKs. Tree-SHA512: 10238ba44ce69ed85b327a9044312410871f8c87c9675b6f54cb0d0d168d2a3d7bd1adcdee0c868e5813b6b566eedb11a9d47323c0f556e3e4111a9c7f841c34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please remove the italicized help prompts before submitting or merging
Provide a general summary of your changes in the Title above. The title must
follow the format described in
CONTRIBUTING.md.
Do not manually line wrap text; allow the GitHub UI to dynamically wrap lines.
CONTRIBUTING.md
describes what is expected of a pull request, including tests, refactoring and
backports.
Pull requests without a rationale and clear improvement may be closed
immediately.
Please provide clear motivation for your patch and explain how it improves
Dash Core user experience or Dash Core developer experience
significantly:
Issue being fixed or feature implemented
What was done?
Describe your changes in detail. For a backport or backports, name the upstream PRs and
explain every omitted hunk.
How Has This Been Tested?
Please describe in detail how you tested your changes: which existing tests
cover the change, which new tests were added and what they observe, or why
no test applies. State only what was actually run.
Include details of your testing environment, and the tests you ran
to see how your change affects other areas of the code, etc.
Breaking Changes
Please describe any breaking changes your code introduces, or state that
there are none.
Checklist: