2.6 KiB
FAIL
Ran bash tests/scripts/references.sh: exit 0, "14 pins match". All 14 reference/* HEADs equal their pins and every worktree is clean. The defects below are gaps that this run cannot catch.
scripts/fetch-references.sh:12 — The "already done" check compares only HEAD against the pin. When HEAD matches, the function returns before lines 19–21, so a changed sparse path list is never applied. The script prints ok and exits 0 with sources missing.
Scenario (reproduced on a scratch copy of reference/libreoffice-core): add vcl/inc to the libreoffice-core sparse list and run the script. It prints ok libreoffice-core 8221e31… and exits 0. reference/libreoffice-core/vcl does not exist, and sparse-checkout list still shows the old five paths. tests/scripts/references.sh also passes, because it only probes LibreOfficeKit.h.
Fix: make the skip condition also require that the recorded sparse set equals the requested paths. For example, compare git sparse-checkout list with "$@". Otherwise re-apply sparse-checkout set on every run.
scripts/fetch-references.sh:38 — mailcore2's pinned dependencies are never checked out. deps/ctemplate, deps/libetpan and deps/tidy-html5 are submodules of the pin, but only mupdf gets submodule update (line 36). git -C reference/mailcore2 submodule status lists all three with - (uninitialized), and deps/libetpan is an empty directory. This breaks "全部 pin 检出". It also leaves C00.4 ("MailCore 2 依赖可构建") with no pinned libetpan, ctemplate or tidy sources: build-mac and build-android consume deps/.
Scenario: run the script on a fresh machine, then try to build MailCore 2 from reference/mailcore2 following build-mac/README.md. The libetpan sources are absent, and the script and test both report success.
Fix: run git -C "$ref/mailcore2" submodule update --init --depth 1 --recursive, the same way as mupdf. Have the test assert this.
tests/scripts/references.sh:25 — Submodule state is checked through a single file, mupdf/thirdparty/freetype/.../freetype.h. The other 17 mupdf submodules (harfbuzz, lcms2, jbig2dec, openjpeg, libjpeg, zlib, …) are never checked for being initialized or for being at the commit the mupdf pin records.
Scenario: git -C reference/mupdf submodule deinit -f thirdparty/harfbuzz, or a submodule left at another commit (+ in submodule status). The test still prints "14 pins match" and exits 0, while C00.4's MuPDF build fails.
Fix: for each repo whose submodules the script fetches (mupdf, and mailcore2 after the fix above), fail when any line of git submodule status --recursive starts with - or +.