Repository navigation
feat(build-project): the reference set includes the platform image's shared frameworks - #2912
Conversation
…shared frameworks Measured on Plugins#1032: every container entry red on Microsoft.Extensions.FileSystemGlobbing — a framework-provided (NU1510-prunable) package that lives in the portal's Microsoft.AspNetCore.App and nowhere in the tester image, whose console runtime carries only Microsoft.NETCore.App. The reference set is the runtime the module LANDS in, so Read gains sharedFrameworksRoot (--shared-frameworks), the lane extracts /usr/share/dotnet/shared from the platform image beside /app and mounts it in, and an explicit root that is missing refuses rather than falling back to the builder's own runtime. Proven: MeshWeaver.AI (168 sources) builds GREEN against the portal /app + its extracted frameworks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the plugin tester’s “container reference set” to include the platform image’s shared frameworks (e.g., Microsoft.AspNetCore.App) when the builder runs in a different image/runtime, aligning reference resolution with the runtime the module actually lands in.
Changes:
- Extends
ContainerReferenceSet.Readwith an optionalsharedFrameworksRootand scans that root for shared-framework assemblies, refusing an explicitly named-but-missing root. - Wires a new
--shared-frameworks <dir>flag throughmw-plugin-test build-projectintoProjectBuild. - Updates the container CI lane to extract and mount
/usr/share/dotnet/sharedfrom the platform image and pass it to the builder; adds tests covering explicit-root resolution and refusal behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tools/MeshWeaver.PluginTester/ProjectBuild.cs | Plumbs SharedFrameworksRoot into the reference-set construction used for builds. |
| tools/MeshWeaver.PluginTester/Program.cs | Adds --shared-frameworks CLI flag and passes it into build options. |
| tools/MeshWeaver.PluginTester/ContainerReferenceSet.cs | Implements shared-framework root override and fail-closed handling when explicitly provided. |
| test/MeshWeaver.PluginTester.Test/ContainerReferenceSetTest.cs | Adds tests validating resolution from explicit shared frameworks root and refusal on missing root. |
| .github/workflows/node-repo-module-pack.yml | Extracts platform shared frameworks and mounts/passes them into the container build-project invocation. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Test Results (shard 0)792 tests 788 ✅ 5m 12s ⏱️ Results for commit cc80cec. |
Test Results (shard 5) 8 files 8 suites 3m 56s ⏱️ Results for commit cc80cec. |
Test Results (shard 1)1 130 tests 1 130 ✅ 4m 0s ⏱️ Results for commit cc80cec. |
Test Results (shard 4)1 165 tests 1 165 ✅ 4m 23s ⏱️ Results for commit cc80cec. |
Test Results (shard 2)3 059 tests 2 867 ✅ 6m 57s ⏱️ Results for commit cc80cec. |
Test Results (shard 3)1 152 tests 1 152 ✅ 7m 44s ⏱️ Results for commit cc80cec. |
Test Results 44 files 44 suites 32m 14s ⏱️ Results for commit cc80cec. |
The first real acceptance run (Plugins#1032) redded every container entry on one name:
Microsoft.Extensions.FileSystemGlobbing. Diagnosis, measured by image content:Microsoft.AspNetCore.App/10.0.11/, so the landing runtime supplies it (the SDK path smuggled a copy inside each bundle's private closure, which the container path rightly doesn't have);Microsoft.NETCore.App, so the builder's own shared-framework probe can't see it.The reference set's own doctrine — the image the module lands into — decides it:
ContainerReferenceSet.ReadgainssharedFrameworksRoot(--shared-frameworks), the lane extracts/usr/share/dotnet/sharedfrom the platform image beside/appand mounts both, and a named root that is missing is a refusal, never a silent fallback to the wrong runtime. Tests cover the resolve-from-explicit-root and refusal paths; empiricallyMeshWeaver.AI(168 sources, the red family's root) builds GREEN with the flag.Also explains why local native measurements over-report: the builder's process TPA legitimately supplies framework assemblies, so local-vs-CI verdicts only converge with this in place.
🤖 Generated with Claude Code