test: the runner check reads the manifest's keys, the MSI payload is found by content, and independent platform steps run after a failure (mcpp#634)

Run 34823714568 measured every P2 criterion on macos-15 (LC_RPATH
@executable_path/../Frameworks and @loader_path; codesign --verify
--deep --strict valid, both signatures flags=0x2(adhoc); exit 7 with
the framework loaded from Contents/Frameworks; exit 134, "Library not
loaded", without it) and then failed its own precondition: the grep for
`runner` matched the fixture's header comment. Comments are removed
before the search.

On windows-2022 the bundle was produced (1126642 bytes beside the
32768-byte MSI), and `wix burn extract` without the bootstrapper
application wrote the payloads under their ids, `a0` and `a1`, so a
search by extension found nothing. The check now extracts with -oba as
well and looks for a payload byte-identical to the MSI. The repeated
"The system cannot find the path specified." lines are mcpp's own
output on Windows: the job log of main's last run (34772006562) carries
twelve of them.

The macOS framework, Metal and iOS steps and the Windows bundle step
run when an earlier step of their job failed, so one run reports each
of their readings.

Author: Sunrisepeak

.github/workflows/ci.yml

@@ -1890,7 +1890,7 @@ jobs:
       # bootstrapper application, chaining the MSI the step above measured, and
       # built through the extension `xim:wix` 5.0.2-1 carries.
       - name: dist-wix produces a Burn bundle that chains the MSI
-        if: runner.os == 'Windows'
+        if: ${{ !cancelled() && runner.os == 'Windows' }}
         timeout-minutes: 20
         working-directory: tests/msi-consumer
         run: MCPP="$MCPP" ./check-setup.sh
@@ -1943,12 +1943,14 @@ jobs:
           echo "ok: one bundle, a valid plist, it launches, and the resource is where NSBundle looks"
 
       # THE CLOSURE AS A FRAMEWORK, ON THE BUNDLE (mcpp#634, B1 to B3). The
-      # plan-level half runs on Linux. This half reads the linked program's
+      # plan-level half runs on Linux. This step, the Metal step and the iOS
+      # step measure independent things, so each runs when an earlier step of
+      # the job failed and the job reports every reading it can take. This half reads the linked program's
       # load commands, verifies the bundle's ad-hoc signature, runs the program
       # with and without its framework, runs the bundle through `mcpp run
       # --format app` with no runner in the manifest, and attaches the image.
       - name: dist-apple carries the closure as a signed framework, runs through macapp-run, and writes a disk image
-        if: runner.os == 'macOS'
+        if: ${{ !cancelled() && runner.os == 'macOS' }}
         timeout-minutes: 30
         working-directory: tests/app-framework-consumer
         run: MCPP="$MCPP" ./check-apple-bundle.sh
@@ -1958,7 +1960,7 @@ jobs:
       # Metal toolchain the script asserts the rule's refusal and annotates the
       # run with a warning that the two criteria are unmeasured.
       - name: rules-metal compiles Metal libraries, or records that this runner has no Metal toolchain
-        if: runner.os == 'macOS'
+        if: ${{ !cancelled() && runner.os == 'macOS' }}
         timeout-minutes: 20
         working-directory: tests/metal-consumer
         run: MCPP="$MCPP" ./check-metal.sh
@@ -1981,7 +1983,7 @@ jobs:
       # gives: "a machine without Xcode should not download a compiler before
       # being told the compiler is not what is missing."
       - name: dist-apple's iOS row produces a bundle the simulator launches
-        if: runner.os == 'macOS'
+        if: ${{ !cancelled() && runner.os == 'macOS' }}
         working-directory: tests/ios-app-consumer
         shell: bash
         run: |

tests/app-framework-consumer/check-apple-bundle.sh

@@ -107,7 +107,9 @@ echo "ok: exit 7 through the framework copy; without it, exit $rc and 'Library n
 
 # ── 4. mcpp run --format app ───────────────────────────────────────────────
 echo "== 4. mcpp run --format app, through the runner dist-apple supplies =="
-if grep -q 'runner' mcpp.toml; then fail "the fixture's manifest names a runner" mcpp.toml; fi
+# The manifest's keys, not its prose: the header comment names the runner this
+# member supplies, so the comments are removed before the search.
+if sed 's/#.*$//' mcpp.toml | grep -q 'runner'; then fail "the fixture's manifest names a runner" mcpp.toml; fi
 # mcpp_run <variant> <mcpp run arguments...>
 mcpp_run() {
     local variant="$1"; shift

tests/msi-consumer/check-setup.sh

@@ -4,8 +4,11 @@
 #   1. `mcpp pack --format setup` writes a Burn bundle named after the product
 #      and the architecture, never `setup.exe`, beside the MSI it chains.
 #   2. The bundle carries that MSI: `wix burn extract` takes the attached
-#      container apart, and the package inside is byte-for-byte the MSI the
-#      first action wrote.
+#      container apart, and one of the payloads inside is byte-for-byte the
+#      MSI the first action wrote. A payload is identified by its content, not
+#      by its file name: extracted without the bootstrapper application, whose
+#      manifest maps the names, the payloads keep their ids (`a0`, `a1`; the
+#      second is the MSI's cabinet), measured on windows-2022.
 #
 # The bundle's user interface is WiX's stock bootstrapper application, which
 # `wix build` finds only through the extension `xim:wix` 5.0.2-1 carries; a
@@ -45,12 +48,18 @@ wix="$home/registry/data/xpkgs/xim-x-wix/5.0.2-1/tool/tools/net6.0/any/wix.exe"
 [ -f "$wix" ] || fail "no wix.exe of xim:wix 5.0.2-1 at $wix"
 out="$PWD/target/setup-extract"
 rm -rf "$out"
-"$wix" burn extract "$(cygpath -w "$bundle")" -o "$(cygpath -w "$out")" > setup-extract.log 2>&1 \
-    || fail "wix burn extract refused the bundle" setup-extract.log
-inside=$(find "$out" -type f -iname '*.msi')
-reading extracted "$(find "$out" -type f | sed "s|^$out/||" | tr '\n' ' ')"
-[ "$(printf '%s\n' "$inside" | grep -c .)" = 1 ] || fail "expected one MSI in the bundle, found: $(echo $inside)" setup-extract.log
-cmp -s "$inside" "$msi" || fail "the MSI inside the bundle ($(size "$inside") bytes) differs from $msi ($(size "$msi") bytes)"
+"$wix" burn extract "$(cygpath -w "$bundle")" -oba "$(cygpath -w "$out/ba")" -o "$(cygpath -w "$out/payloads")" \
+    > setup-extract.log 2>&1 || fail "wix burn extract refused the bundle" setup-extract.log
+# A listing file rather than process substitution, which Git Bash emulates.
+find "$out/payloads" -type f | sort > setup-payloads.log
+reading extracted "$(sed "s|^$out/payloads/||" setup-payloads.log | tr '\n' ' ')"
+[ -s setup-payloads.log ] || fail "wix burn extract wrote no payload" setup-extract.log
+match=""
+while IFS= read -r payload; do
+    if cmp -s "$payload" "$msi"; then match="$payload"; break; fi
+done < setup-payloads.log
+[ -n "$match" ] || fail "no payload in the bundle is byte-for-byte $msi ($(size "$msi") bytes)" setup-payloads.log setup-extract.log
+reading msi-payload "${match#$out/payloads/}, $(size "$match") bytes"
 echo "ok: the bundle's container holds the MSI, byte-for-byte"
 
 echo "PASS: dist-wix writes a Burn bundle that chains the MSI"