You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* ci: pin the build tool this package was released against
The pin was several releases behind, so what CI validated was not what
the ecosystem resolves. 2026.8.24.6 is the version this package's
current contents were released alongside — openkal 0.7.0 and the
implementations that follow it.
A version verified to build this package, not a measured minimum: the
pin exists for reproducibility rather than because an older mcpp is
known to fail.
* ci: pin 2026.8.25.1 — the release that fixes what 2026.8.24.6 broke
* ci: validate against the mcpp under review, before it is released
Several mcpp releases went out green and only then turned this ecosystem
red. The engine's own CI cannot see a defect that appears only in a real
dependency graph, and this repository could not see the engine until it had
been published — so the first place the two met was after the release.
`MCPP_SOURCE_REF` (a workflow_dispatch input, or a repository variable)
names a branch of mcpp-community/mcpp. When set, every job builds that
source with the released mcpp as bootstrap and puts the result first on
PATH; when empty the job tests the released pin exactly as before.
Also re-pins to 2026.8.25.2, which fixes what this repository last failed on.
* ci: one MCPP_SOURCE_REF definition, not two
* ci: bootstrap from the index when validating an unreleased mcpp
The pin may name the very release the run is validating, which does not
exist yet — that is what MCPP_SOURCE_REF is for. Bootstrap from whatever
the index has; the build under review replaces it a step later.
* ci: the clone's workspace pin does not decide which mcpp builds it
`.xlings.json` at mcpp's root pins the mcpp that compiles mcpp, and that
pin does not move when mcpp is released — a build inside the checkout obeys
it and installs a version the index may no longer carry. What this step
wants is the source compiled by the mcpp installed a moment earlier.
* ci: note why the fresh clone needs no mtime sort
The mcpp side of this cross-validation had to sort by mtime — its target/
is restored from a cache and `find … | head -1` returned a binary an
earlier push had left, with the right version string and the wrong code.
Here $src is a fresh clone, so the plain form is correct; `-printf` is a
GNU extension and one of the runners reaching this line is macOS.
* ci: find the built mcpp by either spelling, on every runner
The matrix reaches Windows and macOS. Measured on the Windows row:
`Finished release [optimized] in 173.44s` followed by "mcpp did not
build" — the build had succeeded and the search was looking for a name
that filesystem does not use.
# The branch of the specification this backend is verified against. It
@@ -55,7 +62,15 @@ jobs:
55
62
# of the two situations it is.
56
63
for attempt in 1 2 3 4 5 6; do
57
64
xlings update > /dev/null 2>&1 || true
58
-
if xlings install "mcpp@$MCPP_VERSION" -y -g; then break; fi
65
+
if # ⚠️ THE PIN MAY NAME THE RELEASE THIS RUN IS VALIDATING, which does
66
+
# not exist yet — that is the whole point of MCPP_SOURCE_REF. Bootstrap
67
+
# from whatever the index has; the step below replaces it with the
68
+
# build under review, and the pin is what an ordinary run tests.
69
+
if [ -n "${MCPP_SOURCE_REF:-}" ]; then
70
+
xlings install mcpp -y -g
71
+
else
72
+
xlings install "mcpp@$MCPP_VERSION" -y -g
73
+
fi; then break; fi
59
74
if [ "$attempt" = 6 ]; then
60
75
echo "::error::mcpp@$MCPP_VERSION never appeared in the index (6 attempts over 5 minutes). If it was just released, the pointer has not propagated; if the pin names a version that was never published, it never will."
61
76
exit 1
@@ -65,6 +80,56 @@ jobs:
65
80
done
66
81
mcpp --version
67
82
mcpp self config --mirror GLOBAL
83
+
# ⭐⭐ CROSS-VALIDATION: BUILD THE mcpp UNDER REVIEW AND USE THAT ONE.
84
+
#
85
+
# Empty in the ordinary run, so this job keeps testing the RELEASED
86
+
# mcpp the pin above names. Set it — `workflow_dispatch` input, or the
87
+
# repository variable — and the same job runs against that source.
88
+
#
89
+
# ⚠️ THIS EXISTS BECAUSE THE ORDER USED TO BE WRONG. Several mcpp
90
+
# releases went out green and only then turned this ecosystem red: the
91
+
# engine's own CI cannot see a defect that appears only in a real
92
+
# dependency graph, and this repository could not see the engine until
93
+
# it had been published. Validating before the release closes that gap.
94
+
#
95
+
# The released mcpp installed just above is the bootstrap that compiles
96
+
# it; mcpp builds itself and there is no other compiler for it here.
97
+
if [ -n "${MCPP_SOURCE_REF:-}" ]; then
98
+
src="$RUNNER_TEMP/mcpp-src"
99
+
[ -d "$src" ] || git clone --quiet --depth 1 \
100
+
--branch "$MCPP_SOURCE_REF" \
101
+
https://github.com/mcpp-community/mcpp.git "$src"
102
+
# ⚠️ THE CLONE'S OWN WORKSPACE PIN MUST NOT DECIDE WHICH mcpp
103
+
# BUILDS IT. `.xlings.json` at mcpp's root pins the mcpp that
104
+
# compiles mcpp, and that pin does not move when mcpp is released —
105
+
# so a build inside the checkout obeys it and tries to install a
106
+
# version the index may no longer carry:
107
+
#
108
+
# [error] xlings: version '2026.8.17.1' not found for 'mcpp'
109
+
# available: 2026.8.25.1
110
+
#
111
+
# What is wanted here is the source compiled by the mcpp installed
112
+
# above, which is exactly what removing the file leaves.
113
+
rm -f "$src/.xlings.json"
114
+
( cd "$src" && mcpp build --release )
115
+
# ⚠️ BOTH SPELLINGS, AND NO `-perm`. The matrix reaches Windows and
116
+
# macOS runners too: on Windows the artefact is `mcpp.exe`, and
117
+
# `-perm -u+x` is not a question that filesystem answers the way this
118
+
# expects. Measured: `Finished release [optimized] in 173.44s`
119
+
# followed by "mcpp did not build" — the build had succeeded and the
120
+
# search was looking for the wrong name.
121
+
#
122
+
# `$src` is a FRESH clone each run, so `target/` holds exactly what
123
+
# this step just built; `-printf` would be the safer form on a cached
124
+
# tree and is a GNU extension this must not use.
125
+
built=$(find "$src/target" -type f \
126
+
\( -name mcpp -o -name mcpp.exe \) | head -1)
127
+
[ -n "$built" ] || { echo "::error::mcpp did not build from $MCPP_SOURCE_REF"; exit 1; }
if xlings install "mcpp@$MCPP_VERSION" -y -g; then break; fi
294
+
if # ⚠️ THE PIN MAY NAME THE RELEASE THIS RUN IS VALIDATING, which does
295
+
# not exist yet — that is the whole point of MCPP_SOURCE_REF. Bootstrap
296
+
# from whatever the index has; the step below replaces it with the
297
+
# build under review, and the pin is what an ordinary run tests.
298
+
if [ -n "${MCPP_SOURCE_REF:-}" ]; then
299
+
xlings install mcpp -y -g
300
+
else
301
+
xlings install "mcpp@$MCPP_VERSION" -y -g
302
+
fi; then break; fi
230
303
if [ "$attempt" = 6 ]; then
231
304
echo "::error::mcpp@$MCPP_VERSION never appeared in the index (6 attempts over 5 minutes). If it was just released, the pointer has not propagated; if the pin names a version that was never published, it never will."
232
305
exit 1
@@ -236,6 +309,56 @@ jobs:
236
309
done
237
310
mcpp --version
238
311
mcpp self config --mirror GLOBAL
312
+
# ⭐⭐ CROSS-VALIDATION: BUILD THE mcpp UNDER REVIEW AND USE THAT ONE.
313
+
#
314
+
# Empty in the ordinary run, so this job keeps testing the RELEASED
315
+
# mcpp the pin above names. Set it — `workflow_dispatch` input, or the
316
+
# repository variable — and the same job runs against that source.
317
+
#
318
+
# ⚠️ THIS EXISTS BECAUSE THE ORDER USED TO BE WRONG. Several mcpp
319
+
# releases went out green and only then turned this ecosystem red: the
320
+
# engine's own CI cannot see a defect that appears only in a real
321
+
# dependency graph, and this repository could not see the engine until
322
+
# it had been published. Validating before the release closes that gap.
323
+
#
324
+
# The released mcpp installed just above is the bootstrap that compiles
325
+
# it; mcpp builds itself and there is no other compiler for it here.
326
+
if [ -n "${MCPP_SOURCE_REF:-}" ]; then
327
+
src="$RUNNER_TEMP/mcpp-src"
328
+
[ -d "$src" ] || git clone --quiet --depth 1 \
329
+
--branch "$MCPP_SOURCE_REF" \
330
+
https://github.com/mcpp-community/mcpp.git "$src"
331
+
# ⚠️ THE CLONE'S OWN WORKSPACE PIN MUST NOT DECIDE WHICH mcpp
332
+
# BUILDS IT. `.xlings.json` at mcpp's root pins the mcpp that
333
+
# compiles mcpp, and that pin does not move when mcpp is released —
334
+
# so a build inside the checkout obeys it and tries to install a
335
+
# version the index may no longer carry:
336
+
#
337
+
# [error] xlings: version '2026.8.17.1' not found for 'mcpp'
338
+
# available: 2026.8.25.1
339
+
#
340
+
# What is wanted here is the source compiled by the mcpp installed
341
+
# above, which is exactly what removing the file leaves.
342
+
rm -f "$src/.xlings.json"
343
+
( cd "$src" && mcpp build --release )
344
+
# ⚠️ BOTH SPELLINGS, AND NO `-perm`. The matrix reaches Windows and
345
+
# macOS runners too: on Windows the artefact is `mcpp.exe`, and
346
+
# `-perm -u+x` is not a question that filesystem answers the way this
347
+
# expects. Measured: `Finished release [optimized] in 173.44s`
348
+
# followed by "mcpp did not build" — the build had succeeded and the
349
+
# search was looking for the wrong name.
350
+
#
351
+
# `$src` is a FRESH clone each run, so `target/` holds exactly what
352
+
# this step just built; `-printf` would be the safer form on a cached
353
+
# tree and is a GNU extension this must not use.
354
+
built=$(find "$src/target" -type f \
355
+
\( -name mcpp -o -name mcpp.exe \) | head -1)
356
+
[ -n "$built" ] || { echo "::error::mcpp did not build from $MCPP_SOURCE_REF"; exit 1; }
0 commit comments