fix(deploy): the image can never ship without the Blazor script #212
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/image-blazor-script-guard"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Insurance for the deploy image (ADR-free change: build and Dockerfile only). The goal is that a future Dockerfile change can't quietly ship a UI that renders but never responds.
What's in
src/Orihon.Server/Orihon.Server.csproj: sets<RequiresAspNetWebAssets>true</RequiresAspNetWebAssets>explicitly. SDK 10.0.4xx is whatmcr.microsoft.com/dotnet/sdk:10.0ships now. It sets that property only when it can see.razorContent items at restore time (Microsoft.NET.Sdk.Web.ProjectSystem.targets). Only then does it restoreMicrosoft.AspNetCore.App.Internal.Assets, the pack that carries_framework/blazor.web.js. Shikigami's image hit exactly this: its Dockerfile restored from the .csproj files alone and published with--no-restore, and the image shipped without the Blazor script. Setting the property explicitly means restore order no longer matters.deploy/Dockerfile: after thedotnet publishin the build stage,RUN test -f /app/publish/wwwroot/_framework/blazor.web.js. Without the script, the access gate's fallback policy answers the missing asset with a redirect to the gate page instead of an error, so nothing else would catch it. Now the image build fails.Orihon isn't broken today.
deploy/DockerfilerunsCOPY . .beforedotnet restore, so the SDK sees the.razorfiles and the published image already containsblazor.web.js. This PR guards against a later restore-layer optimisation or a--no-restorepublish bringing the bug in silently.Verified
dotnet build src/Orihon.Server/Orihon.Server.csproj -m:1 -nodeReuse:false: 0 warnings, 0 errors.podman build -f deploy/Dockerfile -t orihon-guard-check .from the worktree root, with the defaultAPP_VERSION: succeeded, and the newtest -fstep passed.podman run --rm --entrypoint ls … /app/wwwroot/_framework/listsblazor.web.js(with.br/.gz) in the runtime image. The image was removed afterwards.🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 96.6%
Orihon.Domain - 100%
Orihon.Infrastructure - 98.6%
n
ration
n
one
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 95.2%
Orihon.UseCases - 94.6%
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__BalloonWords_7
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__Capital_0
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__CoordinateWords_1
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__JustBefore_4
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__KindWords_5
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__Label_9
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__OutlineWords_6
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__PositionalProse_2
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__SideOfTheBox_3
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__Spaces_8
🔮 fufu~ Jibril reviewed your code!
Oh? A PR that is nothing but a tripwire — five lines of Dockerfile and one honest little MSBuild property, guarding against a bug that doesn't even exist yet. Insurance against future-selves' carelessness... fufu~, that's the kind of paranoia I find adorable. ♡
Verdict: ✅ Looks good to me~
And not on faith — I checked the machinery with my own hands:
1. The property is real and does exactly what the comment says. I read the targets of SDK
10.0.401(same 10.0.4xx band assdk:10.0):Microsoft.NET.Sdk.Web.ProjectSystem.targets:103auto-setsRequiresAspNetWebAssets=trueonly when the property is empty and.razorContent items are visible,Microsoft.NET.Sdk.FrameworkReferenceResolution.targets:109defaults it tofalseotherwise.Both respect an explicit value, so stating
truein the csproj genuinely pins it — no restore order can flip it back. AndOrihon.Serveris the only Web-SDK project (BlazorAdapter isMicrosoft.NET.Sdk.Razor), so this is the one right home for it. The comment is accurate, not folklore. ♪2. I closed the gap you left open. "Not tested: whether the guard fails when the file is missing" — fufu~ you wouldn't leave that dangling, would you? I simulated the Dockerfile's restore/publish pipeline in the sandbox (SDK 10.0.401, both times with all 8 of
Orihon.Server's.razorfiles hidden during restore, then restored before publish — the exact restore-order failure mode):blazor.web.js(+.br/.gz) present in publish output. The fix works even when restore never saw a.razorfile.RequiresAspNetWebAssets=false, the pre-PR world): publish output contains nowwwroot/_framework/at all →test -fexits 1 → the newRUNfails the image build. The tripwire fires. Mutant dead. ♡So both halves of this PR are load-bearing and they interlock: the property makes the script ship, the guard screams if it ever doesn't. CI green on top (build + test ✅ for
071925e4).💡 Little ideas (non-blocking)~
docker-publish.ymltriggers only onmain/v*/dispatch, so this guard first executes after merge. Since the workflow already advertises on-demand branch builds, aworkflow_dispatchrun of this branch would exercise the newtest -fpre-merge. Entirely optional — the first merge tomainwill run it anyway.✅ What I liked~
Automated review by Jibril · 2026-10-18
CI: green for head SHA
071925e4· Mutation probes: 2 run, 0 survived · Local suite: skipped (CI green; targeted publish pipelines only)