[zackees]

Refs #651 (measurements and breakdown are in the issue).

Findings: dependency modules are already cached (prebuilt tarballs, 'Cache hit ... skipping build'), ccache is already persisted, and the Flatpak does not build Rust, so soldr/zccache have nothing to cache here. The two big costs are flatpak build-bundle (~4 min, master pushes and schedule only) and flatpak-builder's debuginfo split (~3.5 min, not removable without changing the shipped Debug ref).

Change: build-bundle only for the daily schedule, tags, release branches and Seeking Testers PRs. Routine master pushes skip it. Cache keys are unchanged (manifest hash, commit-keyed ccache), so the build still compiles from source whenever sources or the manifest change.

Baseline (master pushes, bundle on): 12.3 to 20.1 min, median ~17. Cold/warm timings for this PR will be added in a comment below (a PR never builds the bundle, so the saving shows on the next master push).

[zackees]

Results (Refs #651)

What changed (3 commits):

1. build-bundle only for schedule, tags, release branches and Seeking Testers PRs, not routine master pushes (saves the ~4 min flatpak build-bundle; a PR never builds it, so this shows on the next master push, not in the numbers below).
2. cache: true / restore-cache: true always. Root cause of slow cold PR runs: the flatpak-builder action adds --ccache only when cache is true, and the workflow set it false whenever master had no cache for the manifest hash. That PR compiled all ~717 files with no ccache. The gh cache list probe is gone; the action's restore now falls back to the newest flatpak-builder-x86_64 cache (flatpak-builder only reuses a module whose manifest entry and source checksums are unchanged, so changed sources/manifest still build from source).
3. The ccache dir is saved from every full run (PRs included), pruned only on master; a PR restores its own newest entry before master's.

Keys: dependency cache flatpak-builder-<sha256 build-aux/com.obsproject.Studio.json>-x86_64 (action-managed, 2.46 GiB); ccache flatpak-ccache-x86_64-<sha> with restore prefix flatpak-ccache-x86_64-. The obs module is a dir source, so it recompiles on every source change; ccache only skips unchanged translation units.

Run	Condition	Build Flatpak Manifest step	Job
master pushes, baseline (10 runs)	deps+ccache warm, bundle on	584 to 1002 s (781 s typical)	12.3 to 20.1 min (median ~17)
38483172821	cold PR, no --ccache (before fix 2)	886 s	16.3 min
38485924187	cold PR, --ccache but master's ccache stale (0.6% hits)	1214 s	22.4 min
38492490533	deps cache hit, ccache restored	555 s	15.6 min
38495242621	warm: deps hit + ccache 645/645 hits	499 to 506 s	15.0 min

Warm compile phase: ninja 717 steps in ~55 s (cold without ccache: 8 to 13 min). What is left in the 500 s: SDK install ~40 s, compile ~1 min, flatpak-builder debuginfo split/compress ~4 min (not removable without changing the shipped Debug ref; the action has no way to pass --disable-debuginfo-style flags), export ~80 s. The job totals also contain Initialize containers, which varied from 48 s to 347 s (ghcr pull of the flatpak-github-actions image on the runner; outside this workflow's control).

Not done: soldr/zccache (the Flatpak does not build Rust: no ENABLE_RUST_LIBOBS/Corrosion in build-aux/com.obsproject.Studio.json, so there is nothing to cache; no soldr issue needed). publish.yaml keeps its own cache-only-on-hit behavior (release builds stay hermetic).

Notes: first runs on this PR failed on master's obs-websocket breakage (#659/#660, since fixed) and one Windows Tier 2 flake; one Flatpak run failed AppStream validation on a transient HTTP 500 from the github.com URL probe and passed on re-run.