From 0ce3d9c092acd710f54027f59ebf0d5686142797 Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Fri, 11 Sep 2026 15:31:01 +0800 Subject: [PATCH] fix(ci): the registry cache must not carry the resolved index MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `actions/cache` held all of `~/.mcpp/registry`, and that includes `data/xim-pkgindex` and `data/mcpplibs` — the RESOLVED indices, the descriptors mcpp actually reads. The key's `restore-keys` prefix ends at MCPP_VERSION, so a run restored whatever index the previous run left behind, regardless of what had landed upstream in between. THIS ALREADY COST A DAY Two successive fixes to `xim:wix` (openxlings/xim-pkgindex#808, then #809) were each merged, each re-run here, and each appeared to change nothing. Both were read as "the fix does not work" and the second one was written on that false premise. Neither had ever been loaded. The tell was in the logs the whole time: `7zip`, which #809 declares as a dependency, appeared ZERO times in a run that was supposedly testing #809. A fix that is not in the log is not being tested. What eventually refreshed the index was moving MCPP_VERSION for unrelated reasons — a coincidence of cache-key composition, not a mechanism anyone chose. Until then the rule was, in effect: **a change to a xim package cannot be verified from this repo's CI.** EXCLUDE, DO NOT KEY ON IT Adding the index revision to the key would evict everything on every upstream commit. Measured on a developer machine: the two index trees are ~8 MB, `data/xpkgs` is ~28 GB. Re-fetching 8 MB per job is the cheap half and it is the half that has to be current; rebuilding 28 GB because a descriptor changed in another repository is the expensive half and it does not. So the payloads and toolchains stay cached and the indices stop being. --- .github/workflows/validate.yml | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 412ab51..4eaba2c 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -972,7 +972,32 @@ jobs: with: # Holds toolchains AND the built compat packages (data/xpkgs), so a # repeat `mcpp test` rebuilds little. - path: ~/.mcpp/registry + # + # THE INDEX TREES ARE EXCLUDED, and that exclusion is the whole point + # of this entry's shape. `data/xim-pkgindex` and `data/mcpplibs` are + # the RESOLVED indices -- the descriptors mcpp reads. Caching them + # under a key whose `restore-keys` prefix ends at MCPP_VERSION means + # a run restores whatever index the last run happened to leave, no + # matter what landed upstream since. + # + # That is not hypothetical. Two successive fixes to `xim:wix` + # (openxlings/xim-pkgindex#808, then #809) were each merged, each + # re-run here, and each appeared to change nothing -- because neither + # was ever loaded. The tell was that `7zip`, which #809 declares, + # appeared ZERO times in a log that was supposedly testing #809. The + # only thing that ever refreshed the index was moving MCPP_VERSION, + # which is a coincidence of cache-key composition rather than a + # mechanism anyone chose. + # + # Excluding rather than keying on the index revision is deliberate. + # Keying would evict everything on every upstream commit; measured on + # a developer machine, the index trees are ~8 MB against ~28 GB of + # `data/xpkgs`. Re-fetching 8 MB per job is the cheap half, and it is + # the half that has to be current. + path: | + ~/.mcpp/registry + !~/.mcpp/registry/data/xim-pkgindex + !~/.mcpp/registry/data/mcpplibs key: ${{ env.REGISTRY_CACHE_KEY }} restore-keys: | mcpp-registry-${{ runner.os }}-${{ matrix.toolchain }}-${{ env.MCPP_VERSION }}-