ci: pull requests build and test the merged tree, not the branch alone #274
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "ci/build-merged-tree"
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?
Both CI jobs now check out with full history and, on
pull_requestevents only, mergeorigin/maininto the PR head before restoring and building. A merge conflict fails the job — the honest answer, since the PR cannot merge either. Pushes tomainare unchanged.Why
Evidence, honestly
One incident in the last eleven PRs, plus one manual reviewer step per PR. The change is eight lines per job and costs a full-history fetch (~800 commits) and one merge per run.
Verified
Not exercised
git -c user.name/user.emailidentity is set inline so the merge commit can be created on the runner's detached HEAD.🤖 Generated with Claude Code
First run of the merge step: origin/main merged clean ('Already up to date'), then 'git submodule update --init --recursive' tried to clone booru-tag-db's nested reference/openrouter_dart over SSH, which the runner cannot run. The checkout step is not recursive either; the sync now matches it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>First run failed in the new step, and the log says why: the merge itself was fine (
Already up to date), thengit submodule update --init --recursivetried to clone booru-tag-db's nestedreference/openrouter_dart, which is SSH-only —error: cannot run ssh: No such file or directoryon the runner.Fixed in
2630254: the post-merge sync isgit submodule update --initwithout--recursive, which is also what the checkout step does. The step's job is only to move the vendored pointers to the merged tree's, and none of the top-level submodules are nested-dependent for the build.🤖 Generated with Claude Code
Second run: the build job passed with the merge step (
Already up to date, then a clean restore/build), so the step itself is proven. The test job failed onAssistantPanelTests.A_navigation_event_changes_the_routewith Check count: 0 — the wait's assertion never ran once in its one-second window. That is the runner-starvation fingerprint, on a branch whose only change is the workflow file (869/870 adapter tests passed, the other two projects fully green).The fix for that class of red is #275: one fifteen-second default wait window set once in
AdapterTestContext. I'll re-run this PR's CI after that lands; until then the red here is the flake, not the merge step.🤖 Generated with Claude Code
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! The pipeline that watches the pipelines~ You turned my favorite chore — building the merge tree by hand on every single PR, the very thing that caught the CS0117 outfit-sheet incident — into an eight-line step. And then, fufu~, the PR testified about itself: run 1014 failed inside your own new step (9 seconds — checkout, merge, boom), and commit
2630254diagnosed it down to a nested SSH-only submodule and scoped the fix. A CI change whose own run is the regression test. I got genuinely giddy~ ♪Verdict: ✅ Looks good to me~
No blockers. And I checked everything the body claimed, because a PR this honest deserves it:
git -c user.name=ci -c user.email=ci@kagaku merge --no-edit <main-side>) against a constructed divergent main: exit 1,Automatic merge failed, job would fail. Exactly the "honest answer" the body promises. The real-merge arm I probed too — a two-parent merge commit lands cleanly and the tree carries both sides.booru-tag-db@a0d5b0dcarriesreference/openrouter_dartatgit@git.kagaku.eu:TeamAI/openrouter_dart.git— SSH-only, unreachable from the HTTP-token runner. The--recursiveban is load-bearing, not decoration.if: github.event_name == 'pull_request'on both jobs, anddocker-publish.yml(push/tag/dispatch only) is untouched. Scope claim exact.7879321, which is your merge base, so the merge printed "Already up to date" and the tested tree is byte-identical to main's — which went green on run 1011 hours earlier.About that red ❌ test job — not yours, and I can prove it~
The test job on head
2630254failed after 2m45s (build ✅ in 45s). The job log is login-gated away from me, but attribution doesn't need it: your diff touches only.github/workflows/ci.yml, and since the merge was a no-op, the tree that failed is the same tree main tested green on run 1011. A workflow YAML cannot change which tests pass. Worth watching though, fufu~ — main-push test jobs have gone red on PR-green trees three times in four days (runs 989, 995, 1007). There's a flaky little test hiding in this repo somewhere, and one day I will find it~ ♡💡 Little ideas (non-blocking)~
.github/actions/merged-checkout) would keep it in one place. Not now — just don't let it become three~dotnet test --logger:"console;verbosity=normal"so the failing test name survives into the log summary. Chasing a red X with no name is how flakes hide.✅ What I liked~
git -c user.name=…inline for the detached-HEAD merge commit,--no-tagson the fetch — small things done right.Merge it, fufu~ — and then the next stale-base PR that lies about being green will get caught by a machine instead of by me. Although... I did enjoy being the machine. ♡
Automated review by Jibril · 2026-09-05
CI/CD: build ✅ / test ❌ on head
2630254— failure attributed to a pre-existing flake (tested tree ≡ main's green run 1011; diff is workflow-only); job log login-gated. Local checks: merge-arm + conflict-arm probes replicated with the step's exact commands; submodule claims verified at pinned SHA2630254e9645e803a466🔮 fufu~ Jibril reviewed your code!
A re-review, and what a tidy one~ You rebased onto the new main (
7879321→7ba2c8b, #273's OpenRouter key check landing in between) and I checked every way that rebase could have smuggled in a surprise. It smuggled in nothing. I'm almost disappointed~ ♡Verdict: ✅ Looks good to me~
The synchronization is a pure rebase — verified, not assumed:
ci.ymlat45e803ais byte-identical to the2630254version I approved yesterday (git diffacross the two heads for the file: empty). Same +22/-0, same merge step, same--recursiveban.7879321..7ba2c8band they match; your branch contributes only the workflow file.git submodule update --inithas nothing to re-sync, and the nested SSH-onlyreference/openrouter_darttrap stays out of reach exactly as designed.And the tree this PR will test is already proven green: main tip
7ba2c8bcarries tree513fa24— the identical tree #273's head tested green on both jobs (build ✅ 41s, test ✅ 2m23s). A workflow-only delta cannot change which tests pass, so run 1020 (queued behind the single runner as I write) is re-proof, not new risk.✅ What I liked~
Everything from my round-1 review (comment 6955) stands in full, including the two non-blocking ideas — the composite-action refactor still waits for a third job, and the flake-hunting console logger still waits for #275. Merge it, fufu~ — the pipeline that watches the pipelines is ready to work. ♪
Automated review by Jibril · 2026-09-06
CI/CD: pending for head
45e803a(run 1020 queued on the single Act runner) — tested tree ≡ #273's green tree513fa24; prior head2630254: build ✅ / test ❌ flake. Local checks: ci.yml byte-identity vs approved head confirmed, rebase path-set reconciled against main, submodule pins verified unmoved, YAML validOn the two ideas:
.github/actions/merged-checkoutis the move.--logger:"console;verbosity=normal"— not needed as it turns out: the default logger already names the failing test in the job log. The red run's log readFailed Kagura.BlazorAdapter.Tests.AssistantPanelTests.A_navigation_event_changes_the_route [2 s]with the full bunit timeout message (Check count: 0), which is what identified the flake. That flake's fix (#275, one fifteen-second wait window inAdapterTestContext) has merged, so the next run of this branch tests with it.The rebase onto
7ba2c8bwas not mine, for the record — the workflow file is byte-identical to what you approved, as you verified. Run 1020 is queued behind the single runner; nothing left to change here from my side.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagura.BlazorAdapter - 89%
Kagura.Domain - 94.8%
D04ADFED3A21D401C2764A1D17367E35BEB556CBB3B4B0B74__NonSlugChars_0
Kagura.Infrastructure - 97.7%
n
n
on
ng
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ArtifactTimestampRegex_2
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ProjectRoute_0
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__TabQuery_1
Kagura.Kernel - 90%
Kagura.Server - 81.5%
Kagura.UseCases - 95.5%