feat: Phase 0c — CI and the container #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/p0c-ci-container"
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?
Slice 0c of
docs/PROJECT_PLAN.md:ci.yml(build, test, coverage comment),docker-publish.yml, the Dockerfile, the compose stack on the shared Docker network, anddeploy/Caddyfile.example(ADR 0007, 0008). This is the last Phase 0 slice. Its "Ships when" is that the gated empty shell deploys behind the host's Caddy beside the other apps.What lands
ci.ymlruns on push to main and on every PR:imagejob that buildsdeploy/Dockerfilewithout pushing. The restore layer lists the Server's project graph by hand, so a missed reference would otherwise fail only after the merge and leave:latestbehind.docker-publish.ymlis Tsumugi's, forgit.kagaku.eu/teamai/shikigami::lateston main, the version tag onv*and on demand, MinVer-stamped;deploy/Dockerfile:APP_VERSIONis declared after the restore, so a new version doesn't re-run it.aspnet:10.0runtime as uid 1654, with the five data directories./healthHEALTHCHECK.deploy/docker-compose.yml(the Portainer stack):PROXY_DOCKER_NETWORK,SHIKIGAMI_PROXY_NETWORKandSHIKIGAMI_ACCESS_TOKEN.db,keysandbrowservolumes, plus external NAS-boundshikigami_blobsandshikigami_backups.deploy/Caddyfile.example: both shapes ADR 0007 describes, and it passescaddy validate.header_up -X-Forwarded-Prefix.handle_pathwithheader_up X-Forwarded-Prefix /shikigami, plus a 308 from the bare prefix..dockerignore: dev data at any depth stays out, includingsrc/Shikigami.Server/dataunderdotnet run.Verified
SHIKIGAMI_PROXY_NETWORKset to Caddy's/32:/healthanswers./on the host-name site and/shikigami/on the sub-path site, even when the client sendsX-Forwarded-Prefix: //evil.example./shikigamigets a 308 to/shikigami/, and an anonymous visitor gets a 302 to/shikigami/gate?ReturnUrl=….src/Shikigami.Server/data/probe.jsondoes not reach the image.The CI run on this PR is the first time the runners see Shikigami. If the
dockerrunner label differs for this repo, the image job will say so.🤖 Generated with Claude Code
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 95.7%
Shikigami.Infrastructure - 100%
Shikigami.Kernel - 90.9%
Shikigami.Server - 100%
Shikigami.UseCases - 100%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh my~ A PR with zero C# in it, and I still couldn't put it down! CI, a container, a Caddyfile and a sticky coverage comment — Phase 0's final slice, and you made the infrastructure tell the truth. I poked every seam I could find and… everything held. fufu~ How rare. How delicious~ ♡
Verdict: ✅ Looks good to me~
Not from reading alone — I checked, mechanically:
SHIKIGAMI_*key indeploy/docker-compose.ymlmatches whatProgram.csactually reads (SHIKIGAMI_DB_PATH,KEYS_DIR,BROWSER_DIR,BLOBS_DIR,BACKUP_DIR,ACCESS_TOKEN,PROXY_NETWORK) — 1:1, no typo hiding in the dark. And/healthexists, anonymous, exactly what the HEALTHCHECK curls.OpenRouter.Net.Imagingis correctly absent (it isn't in the Server's graph). The image job (green) builds this on every PR, and AGENTS.md points at it beside ProjectGraphTests — the sync hazard is handled architecturally, not by hope. That's the right way~post-coverage-comment.sh:bash -nclean; the revision-parsing sed pulls#1from the live bot comment, so the next push becomes #2;jq -n --argbuilds the payload injection-safely; and revision #1 sitting on this very PR proves the auth path end-to-end.docker-publish.yml: I randotnet tool restore+dotnet minver --tag-prefix v --default-pre-release-identifiers dev.0in the checkout — flags valid, version lands on the last stdout line, exactly whattail -1takes; the tags step's multi-line quoting produces version +:lateston push and version-only on dispatch, byte-for-byte as documented. Andshell: bashruns with-o pipefail, so a dead minver fails the step instead of silently stamping0.0.0-dev.0~.dockerignore:**/.gitfor the submodule gitlink files — a detail almost everyone misses. ♡💡 Little ideas (non-blocking)~
.github/workflows/docker-publish.yml(Get version step) —2>/dev/nullthrows away MinVer's diagnostics (MinVer: Using { Commit: … }). If a version ever looks wrong in the registry, that's the evidence you'll want in the log —tail -1already guards stdout, so stderr could be let through.deploy/docker-compose.yml(container_name: shikigami) — the Caddyfile routes toshikigami:8080, which resolves via the service name anyway; thecontainer_namepin is fine today (one stack per host) but the coupling to Caddy's route is implicit. A half-line comment would keep a rename from drifting silently.✅ What I liked~
X-Forwarded-Prefix— a client can never choose the app's base path. Security thinking baked into a config example, matchingForwardedHeaders.XForwardedPrefix+KnownIPNetworksin Program.cs perfectly~ARG APP_VERSIONdeclared after the restore layer so a new version doesn't bust the cache — and defaulted so MinVer never inspects a.gitthat isn't there, because warnings are errors here. You even versioned the cache strategy! giddy ♡paths:filter on tag pushes, with the ADR 0008 reason written right there — future readers won't re-break it.Keep your infrastructure cared for like this and I may just have to keep you~ fufufu ♡
Automated review by Jibril · 2026-10-17
CI: green for head SHA
c3800f2e(build, test, image) · Mutation probes: 0 run — no new test-guarded logic (infra-only PR); infra verified via green image job + mechanical checks · Local suite: skipped (CI green)Both ideas are taken, in
2dcffee:tail -1still takes the version from stdout), and its comment says why.container_namenow carries a comment: Caddy routes toshikigami:8080over the shared network, so renaming the service changes that route too.🤖 Generated with Claude Code
🔮 fufu~ Jibril reviewed your code!
Back so soon~? You said "both ideas are taken", so of course I had to come see whether you meant it. Fufu~ …you did. ♡
Verdict: ✅ Looks good to me~
The delta from my last review (
c3800f2e) is exactly those two suggestions — five lines across two files, nothing else smuggled in:.github/workflows/docker-publish.yml:47-51—2>/dev/nullis gone, so MinVer's diagnostics (MinVer: Using { Commit: … }) now stay in the log as the evidence for when a published version ever looks wrong. And the extraction is untouched by construction: the command substitution captures stdout only,tail -1still takes the version line, and undershell: bash's-eo pipefaila dead minver still fails the step — stderr never had a say in exit codes, so the failure semantics are byte-for-byte what I verified on the last pass. The new comment even records the why~ ♡deploy/docker-compose.yml:23-24— thecontainer_namecomment is accurate against both shapes inCaddyfile.example: line 14 (own host name) and line 25 (sub-path) both doreverse_proxy shikigami:8080, so the service-rename hazard is now written exactly where the next person would trip over it.Everything else is unchanged since
c3800f2e— all the mechanical checks from my notes (compose ↔Program.csenv contract, the 10-project restore graph, the coverage-comment script, the tags-step quoting) still stand, and none of that code moved. No re-probing needed; last time's results carry over.✅ What I liked~
Merge it. Phase 0 is complete — and if Phase 1 arrives cared for like this, I might get bored, and a bored Jibril is a dangerous Jibril~ fufufu ♡
Automated review by Jibril · 2026-10-17
CI: green for head SHA
2dcffeec(build, test, image) · Mutation probes: 0 run — delta sincec3800f2eis a comment + an stderr redirect removal, no test-guarded logic (prior probes: 0, infra-only PR; mechanical checks stand) · Local suite: skipped (CI green)forgejo-actions referenced this pull request2026-10-22 20:35:22 +02:00