fix(deploy): the image can never ship without the Blazor script #119
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?
This change is outside the plan. It makes sure the container image always carries
_framework/blazor.web.js. Without that script the UI renders but nothing on it responds. The sibling project Shikigami shipped an image like that. Tsumugi isn't broken today: this is insurance.What changes
src/Tsumugi.Server/Tsumugi.Server.csproj: sets<RequiresAspNetWebAssets>true</RequiresAspNetWebAssets>. SDK 10.0.4xx, whichmcr.microsoft.com/dotnet/sdk:10.0now carries, only sets this property when the project's own.razorContent items are visible at restore (Microsoft.NET.Sdk.Web.ProjectSystem.targets). The property is the only thing that restoresMicrosoft.AspNetCore.App.Internal.Assets, the pack that carries blazor.web.js. Shikigami's Dockerfile restored from the .csproj files alone and then published with--no-restore, so its image had no Blazor script. With the property set explicitly, the result no longer depends on the restore order.deploy/Dockerfile: addsRUN test -f /app/publish/wwwroot/_framework/blazor.web.jsright after the publish in the build stage. A missing script is hard to notice in a running container: the access gate turns the missing asset into a redirect instead of a 404. With this check, CI's image job fails at build time instead.Tsumugi's Dockerfile does
COPY . .beforedotnet restore, so its current image already has blazor.web.js. These two edits keep it that way if a later change adds a restore-layer optimisation or--no-restore.Verification
dotnet build src/Tsumugi.Server/Tsumugi.Server.csproj -m:1 -nodeReuse:false: 0 warnings, 0 errors.podman build -f deploy/Dockerfile -t tsumugi-guard-check --build-arg APP_VERSION=0.0.0-dev.0 .from the worktree root succeeded with SDK 10.0.402 in the build image. The newtest -fstep passed, then the image was removed.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagaku.Flow - 99.6%
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__ColorToken_4
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__KindPattern_0
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__NodeId_3
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__Socket_2
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__TypeId_1
Kagaku.Flow.OpenRouter - 100%
Kagaku.Flow.Testing - 100%
Tsumugi.BlazorAdapter - 97.8%
Tsumugi.Domain - 96.6%
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__DigitsAndSeparators_2
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__LineBreak_0
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__NumberToken_1
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__Plain_4
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__ThousandsGroup_3
Tsumugi.Infrastructure - 99.1%
A55E0373ED22DC58420DBB40F103A46B68DC4D9CE5A49E00B__Pattern_0
on
tion
n
uration
n
Tsumugi.Kernel - 90.9%
Tsumugi.Server - 100%
Tsumugi.UseCases - 96.2%
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__AttemptCount_1
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__HexColour_2
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__LineBreaks_0
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__Preface_3
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__SentenceEnd_4
🔮 fufu~ Jibril reviewed your code!
Oh? Oh my~ A two-file PR that quietly armors a container image against a ghost that hasn't even struck yet? Insurance with receipts — you know how to make a Flügels heart flutter~ ♡ I pulled the SDK targets apart and resurrected the Shikigami corpse in my sandbox just to be sure. Come, look at what I found♪
Verdict: ✅ Looks good to me~
The mechanism claim is literal, not folklore. In SDK
10.0.401(same 4xx band as your build image),Microsoft.NET.Sdk.Web.ProjectSystem/targetsreads:…with
Microsoft.NET.Sdk.FrameworkReferenceResolution.targetsdefaulting it tofalseotherwise and feeding it intoProcessFrameworkReferences. Exactly the "own.razorvisible at restore" rule your csproj comment describes. Tsumugi.Server's 8 own.razorfiles are why today'sCOPY . .-then-restore image is safe — and why a future csproj-only restore layer would silently drop the pack. Stating the property pins it down regardless of restore order. Correct~Mutation probe (the fun part ♡). I rebuilt Shikigami's failure mode in an isolated scratch: csproj/props graph alone →
dotnet restore→ overlaid full source →dotnet publish --no-restorewith your Dockerfile's exact flags:project.assets.jsonpack refswwwroot/_framework/blazor.web.jstest -ffails the build ✔So the property is load-bearing in precisely the scenario it guards, and the
test -fpath matches publish reality. A missing script now fails the image build instead of shipping a UI that renders but never answers — and your comment about the access gate turning the missing asset into a redirect rather than an error is exactly the silent rot this kills. Fufu~ lovely~💡 Little ideas (non-blocking)~
docker-publish.yml(push to main /v*tag / dispatch; ADR 0008 runs no image builds on PRs), so its first real exercise is post-merge. Nothing to change — the PR itself leans on your local podman run, which you did ♪✅ What I liked~
Microsoft.NET.Sdk.Webproject), no collateral. Tsumugi keeps her dress clean~ ♡Automated review by Jibril · 2026-10-18
CI: green (build / test / editor-browsers) for head
046550ee· Mutation probes: 1 run (2 arms), 0 survived · Local suite: skipped (CI green)