fix(modules): the THIN lane strips RID globals too — CD's second NETSDK1047 site - #1676
Merged
Conversation
…DK1047 site #1675 fixed the closure lane; the very next CD run failed identically on the THIN lane's Build invocation (AI packs, view packs — every ProjectReferenced module): under CD's per-arch container publish the outer RuntimeIdentifier flows in as a global there as well, demanding RID targets the modules' portable assets files don't have. Same cure, second site: the thin-lane Build now carries the identical RemoveProperties list (plus PrebuiltBakeDir, which must not leak into module builds either), and the RID-agnostic doc note names BOTH lanes. Verified with CD's EXACT invocation shape — multi-RID PublishContainer (-p:ContainerRuntimeIdentifiers linux-x64;linux-arm64 -p:CIRun=true) to a local archive: both per-RID publishes green, module lanes laid out, multi-arch image index built. Plain -r linux-arm64 publish also green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a remaining NETSDK1047 failure in CD multi-arch container publishes by making the THIN lane module-build MSBuild invocation RID-agnostic, matching the intent already applied to the closure lane.
Changes:
- Strip RID/container/publish-mode globals from the thin-lane
MSBuild Targets="Build"viaRemovePropertiesto prevent RID-specific asset-target expectations during per-RID container publish. - Prevent
PrebuiltBakeDirfrom leaking into thin-lane module builds. - Update the in-file documentation note to explicitly cover both lanes.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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.
CD is still red on main: #1675 cured the closure lane, and the next run failed with the identical
NETSDK1047one lane over — the THIN lane'sBuildinvocation (AI packs, Radzen, …) also receives the per-archRuntimeIdentifierglobal under CD's container publish. Same cure, second site: the identical RemoveProperties list on the thin-lane Build (plusPrebuiltBakeDir, which must not leak into module builds either); the RID-agnostic doc note now names both lanes.Verified with CD's exact invocation —
dotnet publish Memex.Portal.Distributed -c Release --no-self-contained -t:PublishContainer -p:ContainerRuntimeIdentifiers='"linux-x64;linux-arm64"' -p:CIRun=trueto a local archive: both per-RID publishes green, module lanes laid out per RID, multi-arch image index built and archived. Plain-r linux-arm64publish also green; Monolith Release-warnaserrorclean.No What's New: CI/deployment fix.
🤖 Generated with Claude Code