fix(deploy): the image ships the Blazor script again #11
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/image-blazor-script"
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?
The container image (ADR 0008) published without
_framework/blazor.web.js, so on staging every page rendered but nothing on it responded. New familiar opened no dialog, and neither did anything else.What's in
mcr.microsoft.com/dotnet/sdk:10.0now carries, setsRequiresAspNetWebAssetsonly when the project has.razorContent items of its own (Microsoft.NET.Sdk.Web.ProjectSystem.targets). Only then does it restoreMicrosoft.AspNetCore.App.Internal.Assets, the pack that carriesblazor.web.js. The Dockerfile restores from the project files alone, before the source is copied in, so the pack is never restored andpublish --no-restoreships without it. SDK 10.0.1xx (local dev) has no such condition, which is whydotnet runand a localdotnet publishworked.App.razorfalls back to the bare_framework/blazor.web.jsURL. That URL then lands on the gate's fallback policy and is redirected to/gate, which serves HTML, and the browser refuses to run it as a script.Shikigami.Server.csprojsetsRequiresAspNetWebAssets=true, so the restore pulls the pack whatever source it can see.deploy/DockerfileaddsRUN test -f /app/publish/wwwroot/_framework/blazor.web.jsafter the publish, so CI's image job fails instead of shipping a dead UI.Verified
git.kagaku.eu/teamai/shikigami:latesthas nowwwroot/_framework. A localpodman buildofmainreproduces that.blazor.web.jsand its fingerprinted endpoint (blazor.web.cd06xom9c5.js), and/_framework/blazor.web.jsanswers 200 unauthenticated.dotnet buildclean.dotnet test: 854/854 green, unchanged, since no code changed.Notes
🤖 Generated with Claude Code
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 93.8%
Shikigami.Domain - 98.5%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 98.2%
on
ration
shot
Shikigami.Kernel - 90.9%
Shikigami.Server - 100%
Shikigami.UseCases - 91.8%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_2
🔮 fufu~ Jibril reviewed your code!
Ooh, a deployment ghost story~ A PR with ten added lines and zero C# — my favorite kind of detective work! A script that vanishes between
dotnet publishand the container, an SDK that changed its mind mid-feature-band, and a UI that renders beautifully but responds to nothing. Delicious~ ♪Verdict: ✅ Looks good to me~
And I didn't just read this one — I reproduced it with my own hands~
.razorfiles →dotnet restore→ unhid →publish --no-restore), first without your property: publish exits 0, silent as a grave, andwwwroot/_framework/is gone entirely — not even a warning, despiteTreatWarningsAsErrors=true. That ismain's image, exactly as diagnosed. The property is load-bearing. ♡RUN test -f /app/publish/wwwroot/_framework/blazor.web.js— the file is absent at precisely the path the guard checks — andci.yml'simagejob (pull_request → build, no push) runs it on every PR. At head7ee9029athat job is green, meaning the guard executed against a real publish output and passed. A regression test that actually bites — fufu~ wonderful~Shikigami.Serveris the only Web-SDK project, so one property at the composition root covers it; BlazorAdapter and the vendored Razor libraries don't shipblazor.web.js(my probe's output still carried_content/and the scoped styles — only_frameworkwent missing). The green image job confirms sufficiency..razor; the gate turns the missing asset into a redirect, not an error) — lean, and exactly where a future reader will need them.No blocking issues, and nothing worth a suggestion — you turned an invisible failure into a loud one in ten lines. That's craftsmanship~ ♡
Automated review by Jibril · 2026-10-18
CI: green for
7ee9029a(build / test / image — the image job ran the new guard) · Mutation probes: 1 run, 0 survived (removingRequiresAspNetWebAssets+ Docker-order restore on SDK 10.0.401 → publish exit 0, no_framework; the Dockerfile guard catches exactly that) · Local suite: skipped (CI green)