mirror of
https://github.com/Kpa-clawbot/meshcore-analyzer.git
synced 2026-09-11 09:26:16 +00:00
efitenandClaude Opus 5
859173f145
Fixes the problem @sylr reported on #1922. ## What is broken **master has produced no completed pipeline result since 2026-08-31.** Thirty-plus runs today alone were cancelled or left queued, while `go-test`, `e2e-test` and `build-and-publish` were passing inside them. The `deploy` job runs on `[self-hosted, meshcore-runner-2]`, and no such runner has picked up a job since at least 2026-08-31. It has no `timeout-minutes`, so it sits queued indefinitely. That job holds its run open, the run holds the concurrency group `ci-refs/heads/master`, and GitHub then cancels every subsequent master push while one waits. Two runs showing it, one from yesterday and one from right now: ```8ce5291b(2026-09-01)89544b1d(2026-09-02) ✅ Go Build & Test ok ✅ Go Build & Test ok 🎭 Playwright E2E ok 🎭 Playwright E2E ok 🏗️ Build & Publish ok 🏗️ Build & Publish ok 🚀 Deploy Staging cancel 🚀 Deploy Staging queued ← runner: none ``` The tests were fine the whole time. Only the deploy hangs, and it takes the branch's pipeline with it. ## What this changes **1. The deploy job is gated on a repository variable.** ```yaml if: | vars.ENABLE_STAGING_DEPLOY == 'true' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') && github.ref == 'refs/heads/master' timeout-minutes: 10 ``` Unset means it does not run. Setting `ENABLE_STAGING_DEPLOY` to `true` in Settings restores the old behaviour with **no code change**. The `timeout-minutes: 10` is there so that enabling it while the runner is still absent fails in ten minutes instead of blocking the branch again. A bare timeout would have unblocked the queue but left master permanently red on a job that cannot succeed while the runner is gone. Gating it means master goes green when the tests pass, which is what a branch pipeline is for. **2. The badges job stops depending on the deploy.** `needs: [deploy]` → `needs: [build-and-publish]`. That job downloads the `go-badges` and `e2e-badges` artifacts and commits them to `.badges/`. It never needed the deploy step, and that dependency is why the coverage badges also stopped updating. `build-and-publish` already requires both test jobs transitively, so ordering is unchanged. ## What this does not change Nothing about what the deploy job *does*. No test job is touched. One file, +26/-2. ## The part that is not mine to fix Why `meshcore-runner-2` is gone is the repository owner's to answer, and they have been unreachable since June, which is what #1922 is about. Whoever brings the runner back flips one variable and the deploy returns exactly as it was. Thanks @sylr — I had been working around this all day by verifying master locally after each batch, without understanding why master never completed. Your report is what made it legible. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Wzwr3eXseyNM7Xj598djjE Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>