From ccc088913f0dbd3d371bfa6516fa08aaae0c1749 Mon Sep 17 00:00:00 2001 From: JSONbored <49853598+JSONbored@users.noreply.github.com> Date: Wed, 22 Jul 2026 23:07:47 -0700 Subject: [PATCH 1/2] fix(ci): build engine before miner publish, auto-merge release-please PRs publish-miner.yml's validate job never built @loopover/engine before building miner, even though miner imports it -- engine's dist/ is gitignored, so this failed with "Cannot find module '@loopover/engine'" the first time miner's build actually exercised that import. Mirrors the existing build step already in publish-mcp.yml. Also auto-merge release-please's own Release PRs (autorelease: pending label only) once CI is green, so multiple packages' Release PRs spend less time open simultaneously -- they all share one .release-please-manifest.json, so any one merging stales every other open Release PR's copy of that file. --- .github/workflows/mcp-release-please.yml | 23 +++++++++++++++++++++++ .github/workflows/publish-miner.yml | 9 +++++++++ 2 files changed, 32 insertions(+) diff --git a/.github/workflows/mcp-release-please.yml b/.github/workflows/mcp-release-please.yml index 25dfec4afc..7491e4c4a3 100644 --- a/.github/workflows/mcp-release-please.yml +++ b/.github/workflows/mcp-release-please.yml @@ -156,6 +156,29 @@ jobs: fi done + # All four packages share ONE .release-please-manifest.json (separate-pull-requests: true still + # means every component reads/writes that same file), so merging any one component's Release PR + # immediately makes every OTHER open Release PR's copy of that file stale, surfacing as a GitHub + # merge conflict -- confirmed live 2026-07-23: PR #8146 (engine-and-dependents) went CONFLICTING + # the moment PR #8145 (ui-kit) merged, purely from manifest-file drift, no real content collision. + # release-please self-heals this by regenerating/force-pushing its own branches on every run, but + # only once someone merges the SIBLING PR that caused the conflict -- the actual fix is shrinking + # the window multiple Release PRs can sit open at once. Auto-merging them the moment CI goes green + # does that: GitHub's own auto-merge only fires once every required check (including this repo's + # full CI suite) passes, so this adds no less scrutiny than a human clicking merge -- it just + # removes the wait for a human to notice. Scoped to the exact "autorelease: pending" label + # release-please's own action applies, so this can never touch a contributor or maintainer PR. + - name: Auto-merge this run's own Release PRs once CI is green + env: + GH_TOKEN: ${{ secrets.RELEASE_PLEASE_TOKEN }} + run: | + set -euo pipefail + numbers="$(gh pr list --repo "$GITHUB_REPOSITORY" --state open --label "autorelease: pending" --json number --jq '.[].number')" + for number in $numbers; do + echo "Enabling auto-merge on release-please PR #$number." + gh pr merge "$number" --repo "$GITHUB_REPOSITORY" --auto --squash || echo "::warning::Could not enable auto-merge on #$number (already enabled, or not yet mergeable) -- continuing." + done + # release-please creates the component tag + GitHub Release with GITHUB_TOKEN, which (by # GitHub's recursion-prevention rule) does NOT fire push/tag-based workflows. workflow_dispatch # IS exempt from that rule, so dispatch the OIDC publish workflow explicitly, telling it diff --git a/.github/workflows/publish-miner.yml b/.github/workflows/publish-miner.yml index 83e2f15b5e..01307a4ccb 100644 --- a/.github/workflows/publish-miner.yml +++ b/.github/workflows/publish-miner.yml @@ -89,6 +89,15 @@ jobs: - name: Install dependencies run: npm ci + # packages/loopover-miner imports @loopover/engine (lib/ams-policy.ts and others). That package's + # dist/ is gitignored (see ci.yml's own build --workspace @loopover/engine step, and + # publish-mcp.yml's identical step for the same reason) -- without building it first, miner's own + # build below fails with "Cannot find module '@loopover/engine' or its corresponding type + # declarations" (TS2307), confirmed live when this validate job actually got exercised for the + # first time against miner code that imports engine. + - name: Build loopover-engine + run: npm run build --workspace @loopover/engine + # Real tsc build (in-place emit -- see packages/loopover-miner/tsconfig.json; the emitted .js/.d.ts # is gitignored, so this is the only place it ever exists), same as ci.yml's own "Build miner CLI" # step, followed by node --check syntax validation over every bin/lib file (the same two-part From 56930e8611a70ff9415113ee50910f00dd016ddb Mon Sep 17 00:00:00 2001 From: JSONbored <49853598+JSONbored@users.noreply.github.com> Date: Wed, 22 Jul 2026 23:15:55 -0700 Subject: [PATCH 2/2] revert(ci): drop auto-merge for release-please PRs User will merge Release PRs manually going forward -- no automation needed here after all. Keeps just the publish-miner.yml engine-build fix from this branch. --- .github/workflows/mcp-release-please.yml | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/.github/workflows/mcp-release-please.yml b/.github/workflows/mcp-release-please.yml index 7491e4c4a3..25dfec4afc 100644 --- a/.github/workflows/mcp-release-please.yml +++ b/.github/workflows/mcp-release-please.yml @@ -156,29 +156,6 @@ jobs: fi done - # All four packages share ONE .release-please-manifest.json (separate-pull-requests: true still - # means every component reads/writes that same file), so merging any one component's Release PR - # immediately makes every OTHER open Release PR's copy of that file stale, surfacing as a GitHub - # merge conflict -- confirmed live 2026-07-23: PR #8146 (engine-and-dependents) went CONFLICTING - # the moment PR #8145 (ui-kit) merged, purely from manifest-file drift, no real content collision. - # release-please self-heals this by regenerating/force-pushing its own branches on every run, but - # only once someone merges the SIBLING PR that caused the conflict -- the actual fix is shrinking - # the window multiple Release PRs can sit open at once. Auto-merging them the moment CI goes green - # does that: GitHub's own auto-merge only fires once every required check (including this repo's - # full CI suite) passes, so this adds no less scrutiny than a human clicking merge -- it just - # removes the wait for a human to notice. Scoped to the exact "autorelease: pending" label - # release-please's own action applies, so this can never touch a contributor or maintainer PR. - - name: Auto-merge this run's own Release PRs once CI is green - env: - GH_TOKEN: ${{ secrets.RELEASE_PLEASE_TOKEN }} - run: | - set -euo pipefail - numbers="$(gh pr list --repo "$GITHUB_REPOSITORY" --state open --label "autorelease: pending" --json number --jq '.[].number')" - for number in $numbers; do - echo "Enabling auto-merge on release-please PR #$number." - gh pr merge "$number" --repo "$GITHUB_REPOSITORY" --auto --squash || echo "::warning::Could not enable auto-merge on #$number (already enabled, or not yet mergeable) -- continuing." - done - # release-please creates the component tag + GitHub Release with GITHUB_TOKEN, which (by # GitHub's recursion-prevention rule) does NOT fire push/tag-based workflows. workflow_dispatch # IS exempt from that rule, so dispatch the OIDC publish workflow explicitly, telling it