From 52d019d5cd604cd074b15840825e6ec6551b2952 Mon Sep 17 00:00:00 2001 From: Sunrisepeak Date: Sun, 11 Oct 2026 11:50:48 +0900 Subject: [PATCH] release canaries: a project's commands do not see XLINGS_BIN The canary job exported XLINGS_BIN, the released xlings that bootstraps mcpp, to every command of the project. xlings' test kit reads the name as the binary under test, so its tests drove the released xlings instead of the one they had just built. With xlings 2026.10.11.2, test_subos_new_template read an instance.json the released xlings does not write, and the canary blocked the 2026.10.11.1 tag. mcpp keeps its xlings through MCPP_VENDORED_XLINGS; the project's commands run without XLINGS_BIN. --- .github/workflows/release-canaries.yml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.github/workflows/release-canaries.yml b/.github/workflows/release-canaries.yml index 922fe8995..8593394ce 100644 --- a/.github/workflows/release-canaries.yml +++ b/.github/workflows/release-canaries.yml @@ -81,6 +81,13 @@ jobs: run: | export MCPP="$CANDIDATE" export MCPP_VENDORED_XLINGS="$XLINGS_BIN" + # The project's commands do not see the name: mcpp has its xlings + # above, and a project may give XLINGS_BIN its own meaning. xlings' + # test kit reads it as the binary under test, so its tests drove the + # released xlings instead of the one they had just built (2026.10.11.1: + # test_subos_new_template read an instance.json the released xlings + # does not write). + unset XLINGS_BIN # The bash running this step, by path (release_canaries.py says why). if [ "$RUNNER_OS" = Windows ]; then export CANARY_BASH="$(cygpath -w "$BASH")"