ci: add build/test pipeline with coverage reporting #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/ci-pipeline"
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?
Summary
Adds CI pipeline adapted from doujin-manager's workflow.
What's included
.github/workflows/ci.yml— two-job build/test pipeline.github/scripts/post-coverage-comment.sh— sticky PR coverage comment script (copied verbatim from doujin-manager)Adaptations for this repo
working-directory: backendpaths: backend/**filtersubmodules: true(NovelAI.ImageGen + booru_tag_db_dart)Pipeline structure
dotnet restore+dotnet build -c Release(fast-fail gate)needs: build) —dotnet test -c Release --collect:"XPlat Code Coverage", then:coverage-report.zip)Verified locally
🔮 fufu~ Jibril reviewed your code!
Oh~? A CI pipeline PR! fufu~ ♡ Jibril adores these — the unglamorous plumbing that makes every other PR trustworthy. And you've adapted it from
doujin-managerwith a proper adaptation table in the description? That's exactly how a port should be documented. Knowledge is for sharing~ ♪I cloned both repos, diffed the full pipeline against the sibling
doujin-managerworkflow, read both changed files end-to-end, verified the project structure (solution, test csproj, central package management), and hex-dumped the auth header bytes to settle a question that fooled me at first glance. Here's what I found~Verdict: ✅ Looks good to me~ ♡
This is a clean, correct port. Nothing rises to blocking. The adaptations are all justified, the script is byte-identical to its proven sibling, and the new code paths are exactly the ones that will be exercised the moment this merges and CI runs.
✅ What I liked~
backend/working-directory, no path filter (single-project, no monorepo — correct, a path filter here would silently skip CI on changes that touchsrc/ortests/),submodules: truefor the twoexternals/deps. Every deviation fromdoujin-managerhas a reason in the diff. fufu~ ♡.github/scripts/post-coverage-comment.shagainstdoujin-manager's copy — zero differences, executable bit (100755) included. And I verified the sibling actually works:doujin-managerPR #52 has a realforgejo-actionscoverage comment posted by this exact script (73.2% total, 5505/7516 lines). That's the strongest possible evidence — it's not theoretical, it's battle-tested.***in the auth header is runner-side masking, not a literal placeholder. I was this close to flagging "you hardcodedtoken ***instead of$GH_TOKEN" — but the hex dump (od -An -c) shows the real bytes aret o k e n $ { G H _ T O K E N }. Forgejo's act runner masks${{ secrets.GITHUB_TOKEN }}in logs, and the masking bleeds into tool output that reads the rendered file. The script is correct. (Good instinct to check, though — Jibril will always check~ ♡)if: github.event_name == 'pull_request'guard on the coverage-comment step is exactly right. Push events tomainhave no PR number, sogithub.event.pull_request.numberwould be empty and the comment step would fail. Gating it means merges to main still build+test+upload the artifact, just without the comment step. Correct.if-no-files-found: erroron the artifact upload — if reportgenerator somehow produces nothing, the step fails loudly instead of silently uploading an empty artifact. Good fail-fast discipline.needs: buildon the test job — proper fast-fail gate. A release build failure won't waste runner time on a doomed test run.--no-buildondotnet testwith an explicit priordotnet build --no-restore— no redundant rebuild, no wasted restore. The restore→build→test chain is correctly chained with--no-restore/--no-buildflags throughout.💡 Little ideas (non-blocking)~
reportgeneratoris re-installed on every run.dotnet tool install --global dotnet-reportgenerator-globaltool --version 5.4.4runs fresh each CI run. If thedotnetrunner image ever caches~/.dotnet/toolsthis is a no-op, but if not it's a few seconds of network on every workflow run. Not worth changing — it matches the sibling exactly and the version pin is good practice. Just a "you coulddotnet tool restoreagainst a.config/dotnet-tools.jsonmanifest one day" thought for when you have three repos all doing this~ ♪paths:filter means CI runs on README-only changes too. You explicitly noted this in the adaptation table ("No path filter — single-project, no monorepo") and it's the right call for a small repo — a path filter is a footgun that can silently skip CI. Just be aware.md-only pushes tomainwill trigger a full build+test. Totally fine for a repo this size.Note: CI has not yet run on this PR (0 comments as of review) — there's a chicken-and-egg where the workflow file doesn't exist on
mainuntil this merges. Your local verification (163/163 passing, clean Release build, cobertura merge confirmed) is the right evidence in the meantime. Once this lands, the next PR will get the real coverage comment~ ♡Thank you for the clean port and the lovely adaptation table. This is how infrastructure PRs should look~ ♡
Automated review by Jibril · 2026-07-05
CI/CD: absent for head SHA
3ebb012(workflow file is introduced by this very PR — chicken-and-egg; will run on subsequent PRs) · Local checks: full diff + full source read of both files, sibling byte-diff verification (script identical to doujin-manager's proven copy; auth-header hex-dump confirmed${GH_TOKEN}is real,***is runner-side masking), project structure verification (solution + test csproj + central package management + executable bit)Fixed the submodule checkout failure.
Root cause:
.gitmodulesused SSH URLs (ssh://git@git.kagaku.eu:2222/TeamAI/...). The CI runner authenticates withGITHUB_TOKENover HTTPS, so it couldn't fetch submodules via SSH.Fix: Changed to relative URLs (
../../TeamAI/...). These resolve to the same server via HTTPS+token in CI, and via SSH locally.This should let both jobs pass on the next run.
Summary
Summary
Coverage
novelai-imagegen-mcp - 66.9%
NovelAI.ImageGen - 3.8%