CNA-BUG-199: Six CI workflows pin August 2026 sharp-runtime commits that lack components CNA's default closure requests (Xml.Serialization off Windows, Resources everywhere), so they stop at configure

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

CNA's default sharp-runtime component closure has requested Xml.Serialization on non-Windows targets since 2026-09-06 and Resources on every target since 2026-09-20. The workflows pinned to sharp-runtime bc8dbf41, f23ded28 or df1b42ab check out revisions that register neither, and sharp-runtime ends configuration with 'Unknown Sharp Runtime component'. The five non-Windows lanes have therefore failed at configure since 2026-09-06; only the Windows content-pipeline lane is broken solely by Resources.

Identifier

CNA-BUG-199

Category

Bug

Subsystem

Build & CI

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Medium (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

None

Affected contract

htmldom-ci.yml, devices-tests.yml, emscripten-multi-renderer-ci.yml, apple-ci.yml, metal-macos-ci.yml and content-pipeline-windows-ci.yml; SHARP_RUNTIME_COMPONENTS

Expected behaviour

Each CI lane configures the snapshot against a Sharp Runtime revision that provides every component the snapshot requests.

Actual behaviour at TARGET

SharpRuntimeConsumption.cmake lists Resources in CNA_SHARP_RUNTIME_DEFAULT_COMPONENTS (added on 2026-09-20 for ResourceContentManager) and, off Windows, Xml.Serialization (added on 2026-09-06 for the math XmlSerializationEXT header). The root CMakeLists.txt passes that list as SHARP_RUNTIME_COMPONENTS before add_subdirectory of the sharp-runtime checkout, and merges every default component back into a cached or user-supplied SHARP_RUNTIME_COMPONENTS (FORCE), so no override can drop them. htmldom-ci.yml, devices-tests.yml and emscripten-multi-renderer-ci.yml check out sharp-runtime bc8dbf41 (2026-08-15); apple-ci.yml (both jobs) and metal-macos-ci.yml f23ded28 (2026-08-15); content-pipeline-windows-ci.yml df1b42ab (2026-08-28). None of the three revisions has modules/resources or modules/xml-serialization, and their cmake/SharpRuntimeComponents.cmake stops with FATAL_ERROR 'Unknown Sharp Runtime component' for an unregistered name. At this snapshot the configure error names Resources first on every lane, because Resources precedes Xml.Serialization in the closure; before 2026-09-20 the non-Windows lanes already stopped on Xml.Serialization. CNA's own plan_software.md records that Xml.Serialization is absent from sharp-runtime df1b42ab. Most other workflows clone a branch head through clone_siblings.sh (the pushed or pull-request branch when sharp-runtime has it, otherwise next); d3d-windows-ci.yml and gdi-windows-ci.yml (manual dispatch only) check out sharp-runtime's default branch with actions/checkout and no ref. Apart from the six pins, the snapshot records no sharp-runtime revision.

Source locations

• cmake/SharpRuntimeConsumption.cmake — CNA_SHARP_RUNTIME_DEFAULT_COMPONENTS (Resources, Xml.Serialization)
• CMakeLists.txt — SHARP_RUNTIME_COMPONENTS cache variable and add_subdirectory of CNA_SHARP_RUNTIME_ROOT
• .github/workflows/htmldom-ci.yml — sharp-runtime pinned to bc8dbf41
• .github/workflows/devices-tests.yml — sharp-runtime pinned to bc8dbf41
• .github/workflows/emscripten-multi-renderer-ci.yml — sharp-runtime pinned to bc8dbf41
• .github/workflows/apple-ci.yml — sharp-runtime pinned to f23ded28 (two jobs)
• .github/workflows/metal-macos-ci.yml — sharp-runtime pinned to f23ded28
• .github/workflows/content-pipeline-windows-ci.yml — sharp-runtime pinned to df1b42ab
• scripts/ci/clone_siblings.sh — branch-head cloning used by the other workflows

Evidence

Checked by reading the workflows and CMake files at 009d40f5, and the three sharp-runtime revisions (tree listing and cmake/SharpRuntimeComponents.cmake) in the local sharp-runtime checkout; nothing executed, and no CI run results are part of the snapshot. The Resources addition is CNA commit 8c1c8b412.

Independent re-verification: Checked by reading the workflows and CMake files at 009d40f5, and the three sharp-runtime revisions (tree listing and cmake/SharpRuntimeComponents.cmake) in the local sharp-runtime checkout; nothing executed, and no CI run results are part of the snapshot. The Resources addition is CNA commit 8c1c8b412 (2026-09-20); Xml.Serialization joined the closure in CNA commit 0794128b6 (2026-09-06), and CNA's own plan_software.md records that Xml.Serialization is absent from sharp-runtime df1b42ab. In the local sharp-runtime checkout, main (last commit 2026-08-22) and develop (df1b42ab) register neither component while next registers both; what GitHub's default branch held when the two manual Windows lanes would be dispatched is not recorded in the snapshot.

Focused reproduction

# Illustrative; not run. A sharp-runtime checkout at the pinned revision:
git -C sharp-runtime checkout bc8dbf4112c6df8a56f08d80517e872ac0e873b3
cmake -S cna -B build -DCNA_SHARP_RUNTIME_ROOT=$PWD/sharp-runtime
# Expected by reading: CMake Error ... Unknown Sharp Runtime component 'Resources'.

Current tests

Nothing compares a workflow's pinned sibling revision with the snapshot's component closure.

Regression test

A configure-only check (or a script test) that resolves each workflow's pinned ref and verifies that every name in CNA_SHARP_RUNTIME_DEFAULT_COMPONENTS is registered there. The fix is bumping the six refs, or recording one sharp-runtime revision that every lane uses.

Blast radius

At this snapshot the HTML_DOM browser suite, the Microsoft::Devices suites, the Emscripten multi-renderer bundle, the macOS and iOS lanes and the Metal lane cannot configure; neither can the Windows content-pipeline lane, which runs only on pushes to content-pipeline-final or by manual dispatch. Lanes that clone a sharp-runtime branch carrying the Resources component (normally next, through clone_siblings.sh) are unaffected; the two manual-dispatch Windows lanes that check out sharp-runtime's default branch depend on that branch's contents, which the snapshot does not record.

Workaround

Configure against a sharp-runtime next checkout that has the Resources component.