fix(ci): ci-fresh-install had two defects, both firing after every release; bundle xlings 2026.8.4.1 - #350
Merged
Conversation
…lease
11 red jobs looked like many problems. It was two, each able to redden the
whole matrix on its own, and neither introduced by any particular release —
both fire after EVERY release. Analysis:
.agents/docs/2026-08-04-ci-fresh-install-two-defects.md
A. THE REPO'S WORKSPACE PIN AMBUSHED THE VERSION UNDER TEST.
`actions/checkout` is the first step, so the repo's .xlings.json — which
pins the BOOTSTRAP mcpp, hand-maintained and deliberately lagging — lands in
the working directory. That pin is directory-scoped and beats anything
installed globally, so the jobs installed MCPP_PIN and then ran something
else, which was not installed at all:
✓ 1 package(s) installed
[error] xlings: version '2026.8.3.2' not found for 'mcpp'
[error] available: 2026.8.3.4
ci-aarch64-fresh-install.yml hit this and solved it by ordering the checkout
last, with a thorough comment. That does not transfer: the `build mcpp`
steps here run `mcpp clean && mcpp run` INSIDE the repo, so a checkout must
be present while mcpp is invoked. The pin goes instead — this workflow
tests the RELEASED mcpp, and the bootstrap pin has no standing in that.
B. wait-index GUARDED A DIFFERENT DISTRIBUTION CHANNEL.
It polled the index's GIT source, which updates the instant the bump PR
merges. The jobs install from the PUBLISHED ARTIFACT (xlings-res/xim-index →
pointer → tarball), which lags git by however long Publish Index Artifact
plus release-CDN propagation takes. Measured on 2026.8.3.5: the guard
reported ready and all 11 jobs then failed with
[error] package 'mcpp@2026.8.3.5' not found
A guard that measures a channel nobody installs from is not a guard. It now
polls the artifact — verified against the live pointer, which resolves
xim-index-e8ad461.tar.gz and does contain the released version.
Both fixes, plus activation (`-u` and `xlings use`) and an ASSERTION, are
collapsed into one shared script, .github/tools/install_released_mcpp.sh, called
from all five jobs. The two Windows install steps move from pwsh to bash to
share it. The knowledge existed in this repo — fully written out in
ci-aarch64's comment — and the other workflow never learned it; a script is
where that stops being a thing people have to remember.
The assertion is the only part that defends against the NEXT one. It evaluates
`mcpp` as resolved through PATH — the binary the later steps actually invoke —
so any future silent redirection becomes a named failure instead of a matrix
that quietly tests the wrong binary and reports green.
It earned that on the bench, twice, before ever reaching CI:
* my first version probed a GUESSED install path instead of PATH. That
verifies a copy nobody runs — the exact mistake the analysis doc is about,
made while writing the fix for it.
* `-u` alone did not move the shim in an isolated environment (payload
reported 2026.8.3.5, shim reported 2026.7.29.1). `xlings use` is a
different code path; both are done now, with the assertion still final.
Also bumps the bundled xlings 2026.7.28.4 → 2026.8.4.1 across all 16 pin sites
(check_version_pins.sh found every one). That release implements the index
snapshot version contract and auto-routing this repo asked for
(openxlings/xlings#476): an index declares the client version it needs, and the
client routes to the newest snapshot it can use — version skew becomes a
routing decision instead of a hard failure. It supplies the half mcpp cannot do
alone, since mcpp does not fetch indexes (update_index shells out to `xlings
update`) and had no way to ask for a specific snapshot. `xlings index list
--json` passes non-`xlings` `requires` keys through verbatim and `xlings index
use` pins. Consuming that from mcpp needs the index to declare `requires.mcpp`
first, so this commit only bumps and verifies: mcpp new/build/run all work
against 2026.8.4.1, and all four platform artifacts (including the aarch64 one
release.yml hardcodes) are published.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
版本
2026.8.4.1。分析文档：.agents/docs/2026-08-04-ci-fresh-install-two-defects.md一、
ci-fresh-install11 个 job 全红 —— 是两个独立缺陷看起来像「很多问题」，实际两个，各自都能单独把整个矩阵打红，而且都不是某次发布引入的 —— 每次发布之后必现。
A. 仓库的 workspace pin 伏击了被测版本
actions/checkout是第一步，于是仓库的.xlings.json（声明自举 mcpp，手工维护、故意滞后）落在工作目录里。它是目录作用域的，在 checkout 内部压过全局安装 —— 于是「装的是MCPP_PIN，跑的是别的，而后者根本没装」：ci-aarch64-fresh-install.yml踩过同一个坑，用「checkout 放最后」解决了，注释写得很完整。但那招在这里用不了：build mcpp步骤要在仓库里跑mcpp clean && mcpp run，checkout 必须在场。所以改为中和那个 pin —— 这个 workflow 验证的是已发布的 mcpp，自举 pin 在这个问题上没有发言权。B.
wait-index守的是另一条分发通道它轮询索引的 git 真源（PR 合入瞬间更新），而 job 从发布出来的 artifact（
xlings-res/xim-index→ 指针 → tarball）安装 —— 后者还要打包 + 过 CDN。2026.8.3.5那次实测：守卫报「就绪」，11 个 job 随后全部测量一条没人从那里安装的通道，不叫守卫。 现在改查 artifact 通道，并已用实时指针验证过提取逻辑（解析出
xim-index-e8ad461.tar.gz，解包后确实含目标版本）。修法：收敛成一个共享脚本
两处修复 + 激活（
-u与xlings use）+ 断言，全部收进.github/tools/install_released_mcpp.sh，5 个 job 共用。两个 Windows 安装步从pwsh改bash以复用同一份实现。这条知识本来就在仓库里 —— 完整写在
ci-aarch64的注释里，而另一个 workflow 从来没学到。脚本是让它不再依赖「有人记得」的地方。断言是唯一能防住下一个的部分。 它对 PATH 解析出来的
mcpp求值 —— 也就是后续步骤真正会执行的那个 —— 于是任何未来的静默重定向都会变成一条点名的失败，而不是一个悄悄测了错二进制却报绿的矩阵。它在上机之前就赚回了成本，两次：
-u单独在隔离环境里没能切动 shim（payload 自报2026.8.3.5，shim 报2026.7.29.1）。xlings use是另一条代码路径，现在两个都做，断言仍是最终判据。二、内带 xlings 升级
2026.7.28.4→2026.8.4.116 个 pin 点由
check_version_pins.sh全数找出并更新。该版本落地了索引快照的版本契约与自动路由（openxlings/xlings#476，由本仓库提出）：索引声明它需要的客户端版本，客户端自动路由到自己能用的最新快照 —— 版本错配从硬失败变成路由决策。
这补上了 mcpp 自己做不到的那一半：mcpp 不下载索引（
update_index就是 shell out 给xlings update），此前无法要求「给我索引版本 X」。新增的xlings index list --json会把requires里非xlings的键原样透传给对应消费者，xlings index use提供钉选。本次只做升级与验证，mcpp 侧消费这套接口需要索引先声明
requires.mcpp：xlings index list --json实测可用，requires字段按设计透传2026.8.4.1下new/build/run实测正常验证
check_version_pins.shwait-index新逻辑