ci: cache the C/C++ half, link with mold, fix the debug/release cache collision, consolidate the Apple and Windows-client workflows #191

Merged

enricobuehler merged 3 commits from worktree-ci-optimization into main 2026-08-13 10:41:58 +00:00

Conversation 0 Commits 3 Files Changed 30

+1454 -1057

3 Commits

Author	SHA1	Message	Date
enricobuehler	0bfc7fe913	ci: fold release.yml into apple.yml and the two Windows client workflows into one ... Two merges, both of which exist to express an ordering Gitea cannot express across files, and both of which delete a duplicated build. release.yml -> apple.yml (as the `distribute` job) The name described neither what it did (Apple only — every other platform's release is its own packaging workflow attaching to the same Gitea release on a v* tag, with announce.yml as the manual "go") nor anything a reader would guess. The name was the smaller problem. Gitea has no cross-workflow `needs`, so nothing sequenced it against apple.yml's tests: a canary main push uploaded iOS, macOS and tvOS builds to TestFlight even when `swift test` had just failed on that same commit. It is now `needs: swift`, which is only expressible in one file. The two files' paths: filters had also drifted — apple.yml watched crates/**, release.yml watched crates/punktfunk-core/**. The merged filter takes the NARROW one, because that is the correct one: everything on this runner is built from punktfunk-core via build-xcframework.sh, and punktfunk-core's only path dependency is its own vendored fec-rs. That is checkable in one command, and the header says so, and says to widen it if that ever stops being true. Net effect on the shared mac mini: pushes that touch host-side crates no longer build or upload anything Apple. windows.yml + windows-msix.yml -> windows-client.yml The pair built the same three crates FOUR times per client push on ONE runner: debug x64 + arm64 for lint/test, release x64 + arm64 for packaging. windows-host.yml already records why a second (debug) dep tree on this machine is a liability rather than a cost — it re-runs openh264-sys2's vendored C++ through cc-rs's cl.exe fan-out and tips the runner into C1069, which is disk exhaustion wearing a compiler error's clothes. So there is one release build per arch now and clippy/fmt/test run against it, exactly as windows-host.yml does. The paths list went from three copies to one; PRs get the build/lint/test signal and stop before packaging. The rename is safe, and this is worth recording because the GitHub instinct is wrong here: `github.run_number` is REPO-WIDE in Gitea, not per-workflow — consecutive runs of DIFFERENT workflows get consecutive numbers (verified against the API: android 13226, apple 13227, arch 13228, ci 13229, deb 13230). The canary MSIX version <minor>.<run>.0 and Apple's CURRENT_PROJECT_VERSION therefore keep climbing across a rename. On GitHub the same rename would reset both to 1, sorting every new canary below the published ones and getting the TestFlight uploads rejected outright. 25 workflows, down from 27, and every `name:` now matches its filename. Cross-references in windows-host.yml, windows-drivers.yml, android.yml, flatpak.yml, sbom.yml, the provisioning scripts, gitea-release.sh and clients/windows/packaging/README.md updated.	2026-08-13 12:10:36 +02:00
enricobuehler	3f7fbf1061	ci: build the web console once per push instead of once per packaging job ... The Nitro console bundle is a pure function of web/ and sdk/, and it was being built six times on every push: ci.yml, deb, both RPM legs (f43 + f44), arch, and the docker app image, at roughly 2.5 min each. windows-host.yml has cached it on exactly this shape for a while — this extends the same arrangement to the Linux packaging legs, sharing one key family so whichever job builds it first warms the others. The bun version is part of the key. Each builder image runs the bun.sh installer at image-build time, so rust-ci, fedora-rpm and arch-ci can drift apart; keying on it means they share while they agree and simply stop sharing when they do not, rather than one image's bun silently producing the bundle another image ships. Each packaging path needed a different hand-off: * deb — build-web-deb.sh already builds only if web/.output is missing, so the restore alone is enough; the workflow's build+smoke step is now gated on the miss. * arch — makepkg builds with PF_SRCDIR pointing at the workspace, so a restored bundle is already where it needs to be. PKGBUILD gains the same build-if-missing guard the deb script has. * rpm — neither direction works by default. build-rpm.sh packages a `git archive` tarball and web/.output is gitignored, so a bundle in the workspace is invisible to rpmbuild; and the spec's own build lands in rpmbuild's %{_topdir}, which build-rpm.sh mktemps and removes on EXIT, so a console built there is gone before the cache's post step and the cache would never populate — every run a miss that quietly rebuilt. So the workflow builds it, and hands it over by absolute path through a new optional `pf_prebuilt_web` macro. Undefined (plain rpmbuild, COPR) takes the original build path. Every path asserts the bundle exists and carries the Bun.serve marker, on cache hits too. A cache is one more place a wrong artifact can come from, and the packaging scripts' build-if-missing behaviour — correct for a local build — would otherwise turn a broken restore into either a silent rebuild or, with the build step skipped, a package with no console in it. That is not hypothetical: windows-host.yml shipped 0.22.1 and 0.22.2 with no console because an unset path variable was handled by a single Write-Host, which is why its equivalent step throws.	2026-08-13 12:01:09 +02:00
enricobuehler	f1dc6c9f94	ci: cache the C/C++ half, link with mold, and split the debug/release target caches ... Three independent reasons Rust CI stayed slow despite sccache, fixed together because they share the same measurement. 1. sccache only ever covered RUSTC. Every C/C++ dependency in the tree — aws-lc-sys, openh264-sys2's vendored C++, the CMake-built libopus behind audiopus_sys — was compiled from scratch on every job of every workflow. CMAKE_{C,CXX}_COMPILER_LAUNCHER plus CC_/CXX_x86_64_unknown_linux_gnu route both build-script styles (cc-rs and cmake-rs) through the same shared cache. The CC_* vars are JOB-scoped in ci.yml and deb.yml, never workflow-scoped: the arm64 cross image sets its own CC_x86_64_unknown_linux_gnu=pf-host-cc, the wrapper that keeps ffmpeg-sys-next's host probe off the arm64 include dirs. Overwriting it would surface as a header mismatch rather than as a CI config error. 2. Linking is cacheable by nothing, and these jobs relink the host, client, session, cli, worker and tray on every run — twice per push for rpm (f43 + f44). The four Linux builder images now install mold and carry a $CARGO_HOME/config.toml that uses it for x86_64. aarch64 is deliberately left alone (cross driver, already-fast legs). Each image asserts `mold --version` in its build, so an image can never ship the flag without the linker: docker.yml goes red and :latest stays on the last good one. 3. THE EXPENSIVE ONE. ci.yml (debug) and deb.yml (release) named a byte-identical target-cache key, under a comment claiming the release build reused ci.yml's artifacts. It never could. actions/cache is first-saver-wins on an exact key and ci.yml is the faster job, so the shared key always held a debug-only target/ — and, worse, deb.yml could then never save its own, because the key was taken. Every canary .deb has been a from-scratch release build for as long as both keys existed. Same collision on the arm64 pair, and a third participant in linux-client-screenshots.yml. Split into -debug-/-release- key families; that job reads deb's tree via restore-keys but keeps its own exact key so it can never win the save race and replace a full tree with its single-crate one. Also: one scripts/ci/ensure-sccache.sh replaces ten copy-pasted bootstrap blocks that had already drifted into two dialects (GNU tar --wildcards vs bsdtar), every Rust job now ends with --show-stats so a cache regression is visible instead of just "CI got slower", and deb.yml's web install joins every other CI install on --ignore-scripts. No behaviour change to any artifact: same compilers, same flags, same outputs.	2026-08-13 11:57:13 +02:00