ci: wire ccache into the packaging matrix (skipped on tag builds) - #903
Merged
Merged
Conversation
got3nks
force-pushed
the
ci/packaging-ccache
branch
3 times, most recently
from
June 7, 2026 15:36
ed919b7 to
cd7d6fe
Compare
Mirrors the pattern already in .github/workflows/ccpp.yml: install
ccache on each compile job, persist its cache dir across runs via
actions/cache, zero the stats before build, print them after.
Wired across the four compile jobs in packaging.yml:
* appimage (x86_64 + aarch64) -- apt install ccache; cache key
keyed on runner.os + matrix.arch + a hash of CMakeLists.txt
+ cmake/.
* flatpak (x86_64 + aarch64) -- the build runs inside a flatpak-
builder sandbox that doesn't see the host's CCACHE_DIR.
flatpak-builder's --ccache option (added to packaging/linux/
build.sh) sets up ccache inside the sandbox using
~/.cache/flatpak-builder/ccache on the host; that's what's
persisted here.
* macos (arm64 + x86_64-via-Rosetta) -- brew install ccache;
cache key keyed on runner.os + matrix.arch + the same hash.
* windows-zip (x64 + arm64) -- ${pkg_prefix}-ccache via MSYS2
pacman in the existing setup-msys2 install list.
CCACHE_DIR and CCACHE_MAXSIZE live in the top-level env block (1G,
up from the 500M used in ccpp.yml -- the packaging build pulls in
the full BUILD_EVERYTHING set, so the cache works harder).
Tag-build gate: every cache step (restore / save / zero-stats /
show-stats) is guarded by `if: github.event_name != 'workflow_call'`.
Tag pushes trigger release.yml which invokes packaging.yml as a
reusable workflow, so release artifacts always come from a cold
compile. The install of ccache itself is unconditional, but with
no warm cache the build runs at the same speed as before.
windows-installer is untouched: that job bundles the existing
portable .zip and runs makensis -- no compilation, nothing for
ccache to cache.
Expected wall-clock improvement on warm runs: the cmake --build
phase is 60-80% of each job's total; ccache should skip most of
it on a same-branch second run. Cold runs and tag builds pay the
same cost as today.
got3nks
force-pushed
the
ci/packaging-ccache
branch
from
June 7, 2026 16:48
8514368 to
147e165
Compare
got3nks
marked this pull request as ready for review
June 7, 2026 18:08
Contributor
Author
|
Validated end-to-end on got3nks/amule: Cold run (all 8 compile jobs): success, every cache step populated its key.
Warm run (same branch, second invocation): success, every cache step restored its key from the cold run. Cmake-level hit rates (
Flatpak doesn't surface Wall-clock cold-vs-warm across all platforms:
The longest bar in the pipeline (cold macOS x86_64 + Universal2 merge) drops from ~33 min to ~20 min on the warm path — the full packaging matrix's critical path tightens proportionally. Behavioural notes:
|
Contributor
|
Excellent! |
got3nks
added a commit
to got3nks/amule
that referenced
this pull request
Jun 7, 2026
…ule-project#912) Extends existing categories (preferring extensions over new lines): - Performance/Upload: amule-project#898 SlotAllocation default raised. - Networking & Discovery: wire-parser hardening list extended with amule-project#879/amule-project#882/amule-project#890/amule-project#886; new amuleweb security hardening bullet consolidating ngosang's amule-project#869-amule-project#874 triage (all landed in amule-project#875); amulegui list extended with amule-project#857; shared-folder watcher extended with amule-project#858. - Packaging: Windows installer i18n line extended with amule-project#899. - Internals & Refactoring: new docs-polish + code-quality bullets covering amule-project#851/amule-project#855/amule-project#862/amule-project#888/amule-project#900/amule-project#866/amule-project#867/amule-project#895 and amule-project#909/amule-project#910/amule-project#912. - Translations: new pre-release final-wave bullet covering amule-project#847/amule-project#856/ amule-project#891/amule-project#908/amule-project#860/amule-project#904/amule-project#859/amule-project#863/amule-project#861/amule-project#880/amule-project#911/amule-project#901/amule-project#902/amule-project#889/amule-project#868/amule-project#853. - Bug Fixes & Stability: amule-project#850/amule-project#854/amule-project#878/amule-project#906. - CI: ccache wiring (amule-project#892, amule-project#903) + CodeQL binutils-dev (amule-project#907). Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif (both first-time contributors). PR index extended through amule-project#912.
mrjimenez
pushed a commit
that referenced
this pull request
Jun 8, 2026
Extends existing categories (preferring extensions over new lines): - Performance/Upload: #898 SlotAllocation default raised. - Networking & Discovery: wire-parser hardening list extended with #879/#882/#890/#886; new amuleweb security hardening bullet consolidating ngosang's #869-#874 triage (all landed in #875); amulegui list extended with #857; shared-folder watcher extended with #858. - Packaging: Windows installer i18n line extended with #899. - Internals & Refactoring: new docs-polish + code-quality bullets covering #851/#855/#862/#888/#900/#866/#867/#895 and #909/#910/#912. - Translations: new pre-release final-wave bullet covering #847/#856/ #891/#908/#860/#904/#859/#863/#861/#880/#911/#901/#902/#889/#868/#853. - Bug Fixes & Stability: #850/#854/#878/#906. - CI: ccache wiring (#892, #903) + CodeQL binutils-dev (#907). Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif (both first-time contributors). PR index extended through #912.
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.
Mirrors the pattern @mrjimenez wired into
.github/workflows/ccpp.ymlrecently — install ccache on each compile job, persist its cache dir across runs viaactions/cache, zero the stats before build, print them after.What this covers
Four compile jobs in
packaging.yml:appimage(x86_64 + aarch64)apt install ccache$CCACHE_DIR(=${{ github.workspace }}/.ccache)flatpak(x86_64 + aarch64)apt install ccache+flatpak-builder --ccache(added topackaging/linux/build.sh)$CCACHE_DIR(flatpak-builder honoursCCACHE_DIRwhen absolute — seebuilder-context.c:213-222)macos(arm64 + x86_64-via-Rosetta)brew install ccacheper matrix prefix$CCACHE_DIRwindows-zip(x64 + arm64)${pkg_prefix}-ccachevia MSYS2 pacman$CCACHE_DIRwindows-installeris intentionally untouched: it bundles the existing portable.zipartifact and runsmakensis— no compilation, nothing for ccache to do.CCACHE_DIRandCCACHE_MAXSIZElive in the top-levelenv:block.MAXSIZE=1G(up from the 500M used inccpp.yml— packaging pulls in the fullBUILD_EVERYTHINGset, so the cache works harder).Tag-build gate
Every cache-related step (
actions/cache/restore,actions/cache/save,ccache --zero-stats,ccache --show-stats) is guarded byif: github.event_name != 'workflow_call'. Tag pushes triggerrelease.ymlwhich callspackaging.ymlas a reusable workflow, so release artifacts are always produced from a cold compile — belt-and-suspenders against any "could ccache be lying to me" concern on a binary that's about to ship.The install step (
apt/brew/pacman install ccache) is unconditional. With no warm cache, cmake's auto-detection still wires ccache as the compiler launcher, but every TU misses → recompile → cache populated locally for that run only. Same wall-clock as today; no harm.Expected impact
The cmake
--buildphase is 60–80% of each compile job's wall-clock. Warm cache should skip most of it on a same-branch second run; the first run on each branch + tag builds + cold caches all pay the same cost as today.Refs
The ccpp.yml ccache PR series this builds on: b18c0b8 / 143424a / a485a76 / ee7145b / 01c39f1.
Test plan
Validated end-to-end on my fork (got3nks/amule).
Cmake-level hit rates (warm run):
Flatpak ccache stats live inside the SDK sandbox and aren't surfaced by the workflow, but the wall-clock drop is the proxy: aarch64 22m55s → 14m49s (-35%), x86_64 30m13s → 16m28s (-46%).