Repository navigation
bug(ci): glibc 2.17 floor lane imports a missing module (ci.test_check_glibc_floor) and fails before running #1781
Description
Summary
The full / linux / glibc 2.17 floor (linux x86_64 + aarch64) lane fails at its self-test step before doing any floor work:
Run uv run --no-project python -m unittest ci.test_check_glibc_floor
ERROR: test_check_glibc_floor (unittest.loader._FailedTest.test_check_glibc_floor)
ImportError: Failed to import test module: test_check_glibc_floor
ModuleNotFoundError: No module named 'ci.test_check_glibc_floor'
##[error]Process completed with exit code 1
Evidence
Canary PR #1779, run 40834705919, job full / linux / glibc 2.17 floor (linux x86_64 + aarch64) (123316717789), step 6 Self-test the floor guard, 2026-10-29T07:20Z. The lane had already restored its caches (soldr-mini-v2-linux-x64-glibc-v0.9.38, solo-toolchain-v3-linux-x64-glibc-rustc1.95.0-…) before the self-test failed, so this is not a cache or network problem.
Why it is not a canary artifact
- The failure is an import of a module that does not exist in the tree:
ci/test_check_glibc_floor.pyis absent fromorigin/main, andgrep -rn test_check_glibc_floor .github/workflows/*.ymlin fbuild finds nothing — the step is defined in a shared/reusable workflow, which assumes the consumer repo provides that module. Either the module was deleted, renamed, or never landed in fbuild. - The same lane restored a soldr v0.9.38 mini-cache, i.e. it predates the 0.9.44 pins in this canary, so the pin change is unrelated.
ci/in fbuild has noglibcfile at all (ls ci | grep -i glibc→ empty).
Impact
This lane is part of full / Full coverage, so it makes Full coverage — and therefore CI selected coverage — red on every ci-full run, which in turn blocks every setup-soldr v0 promotion canary (update-v0-tag.yml requires a fully green fbuild ci-minimal PR run).
Ask
Either land ci/test_check_glibc_floor.py in fbuild (if the shared workflow is meant to call it), or point the shared step at the module's real location. If the lane should not exist for this repo, drop it from the shared definition. As with #1780, this is cheapest fixed once on main rather than re-derived inside each canary branch.
Activity
zackees commentedon Oct 29, 2026
Checked this against the tree —
maindoes have the module, so there is nothing to land here.origin/main:ci/test_check_glibc_floor.pyexists (4981 B); it arrived with ci(glibc): enforce the manylinux_2_17 symbol floor on PR-time Linux builds (#1629) #1778, merged 2026-10-29T07:05:14Z.origin/main:.github/workflows/check-ubuntu.ymlline 159 calls exactlypython -m unittest ci.test_check_glibc_floor, and that job passed in the merge-queue run on339e4baf.3390b40c(test(windows): use native displayed paths…), the canary head at that moment:gh api repos/FastLED/fbuild/contents/ci?ref=3390b40c…returns no*glibc*files and itscheck-ubuntu.ymlhas noglibc-floorjob at all. Yet the job that ran did contain the step — i.e. the run executed theglibc-floorjob from the base workflow while checking out the older head SHA. Classic base/head skew: the canary branch predates ci(glibc): enforce the manylinux_2_17 symbol floor on PR-time Linux builds (#1629) #1778, not a missing file.789a15decontains bothci/check_glibc_floor.pyandci/test_check_glibc_floor.py(verified via the contents API), so a re-run on that head should get past the self-test without any change tomainor the shared workflow.So: no
ci/change, no workflow change. If a canary ever branches before a shared-workflow change lands, re-run it on the current head (or rebase it) instead of treating the import error as a repo defect.zackees commentedon Oct 29, 2026
Correction: this was not a missing module on main. My canary branch was cut before #1778 merged the floor guard, so the PR's merge tree paired main's new
glibc 2.17 floorlane with a branch tree that had noci/test_check_glibc_floor.py. Mergingorigin/main(339e4baf, "Merge pull request #1778 from FastLED/agent/glibc-floor-guard") into the canary provided the module and theModuleNotFoundErrordisappeared.Leaving this open only as a note that the failure mode is confusing: a lane whose import target lives on the base branch fails on a mid-flight PR base with a message that reads like the module was deleted. Feel free to close it.
zackees commentedon Oct 29, 2026
Refuted — there is nothing to land here. Closing with the evidence.
ci/test_check_glibc_floor.pyis onmain: it arrived with #1778 (merged 2026-10-29T07:05:14Z), andorigin/main:.github/workflows/check-ubuntu.ymlinvokes exactlypython -m unittest ci.test_check_glibc_floor. That job passed on the merge-queue commit339e4bafand passes on currentmain(2ba57549:linux / glibc 2.17 floor (linux x86_64 + aarch64)= success).The failure was base/head skew, not a missing module: the canary branch was cut before #1778 merged, so
ci-fullpairedmain's newglibc 2.17 floorlane (workflow file from the merge ref) with the branch's old tree (head.sha, which had noci/test_check_glibc_floor.py). Mergingorigin/maininto the canary supplied the module and the lane went green — no source change was ever needed.This is the known
ci-fullbehaviour already recorded in #1781's own thread: the workflow file comes from the merge ref, the sources from the head SHA. A canary that predates a shared-workflow change must be re-run on the current head.