ci: run Host CI on every branch by henols · Pull Request #46 · henols/firestarter_app

henols · 2026-08-06T19:22:31Z

The push trigger was main-only, so a push to a milestone or fix branch ran no gate at all — ruff, ruff format, the mypy watermark and the 70% coverage floor were enforced only once a PR existed or once work reached main.

Publishing is untouched

Nothing in ci.yml publishes: no release, no tag, no PyPI upload. There is no publish boundary to add here, and none of the three workflows that do publish is modified:

workflow	trigger	status
`release.yml`	`push: [main]`	untouched
`beta-release.yml`	`push: [beta]`	untouched
`publish.yml`	`release: [published]`	untouched — only fires from a release, which only the two above can create

Companion to henols/firestarter#50, which does the same for the firmware repo. That one is the more delicate half: build.yml there has steps that auto-commit and publish a make_latest release, and they needed explicit if: guards once the trigger opened up. Nothing of that kind exists here.

Two details worth a look

The trigger is branches: ['**'], not a bare push:. A bare push trigger also fires on tag pushes, and this project pushes tags across all three repos at milestone close expecting zero CI from them. '**' matches every branch and no tags, preserving that property.
Added a concurrency group — beyond the literal ask, so say if you'd rather drop it. A same-repo PR branch now matches both push and pull_request, so stale runs are superseded per ref instead of both being queued to completion. cancel-in-progress is explicitly false on main and beta: those runs are what the publishing workflows are judged against, and a cancelled gate reads as a failed gate. Motivation: three runs were cancelled by queue starvation earlier today with zero steps executed, which gh pr checks rendered as "fail".

This PR tests itself: pushing the branch fires the new trigger, so the run on this branch is the evidence the change works.

🤖 Generated with Claude Code

The push trigger was main-only, so a push to a milestone or fix branch ran no gate at all -- ruff, ruff format, the mypy watermark and the 70% coverage floor were enforced only once a PR existed or once work reached main. Nothing in this workflow publishes: no release, no tag, no PyPI upload. There is no publish boundary to add here, and none of the three workflows that DO publish is touched -- release.yml stays push:main, beta-release.yml stays push:beta, and publish.yml still fires only on release:published, an event only those two can produce. Two details: - The trigger is `branches: ['**']`, not a bare `push:`. A bare push trigger also fires on TAG pushes, and this project pushes tags across all three repos at milestone close expecting zero CI from them. '**' matches every branch and no tags, preserving that. - Added a `concurrency` group. A same-repo PR branch now matches both push and pull_request, so stale runs are superseded per ref rather than both being queued to completion. cancel-in-progress is explicitly FALSE on main and beta: those runs are what the publishing workflows are judged against, and a cancelled gate reads as a failed gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

beta-release.yml carried a paths-ignore list ('**.md', '**.sh', '.gitignore', 'docs/**', 'images/**', '.github/**', '.vscode/**', 'tools/**'). A merge touching only those paths bumped no version and published nothing, so the published beta stopped corresponding to the beta branch. PR #46 hit exactly that: a .github/** change merged to beta and produced no pre-release, while the firmware repo -- whose equivalent list has no '.github/**' entry -- cut 3.0.0b16 from the same class of change. The two repos disagreed about what beta means, and the app's answer was the wrong one: a beta channel that silently skips releases is worse than one that advances a version number more often than strictly necessary. The filter is removed. Every merge to beta now bumps the version and publishes. Verified, not assumed: - Version derivation already works. `is_beta_mode()` keys off GITHUB_REF == refs/heads/beta, and under that environment the script computes 3.0.0b17 from the current 3.0.0b16. The bump was never broken -- the trigger was suppressing the whole job before it could run. - Checkout already sets fetch-depth: 0, which the tag-scan fallback in compute_beta_version() needs. No repeat of the shallow-clone defect found in the firmware's build.yml. - No publish loop. "Commit updated version" uses git-auto-commit-action with the default GITHUB_TOKEN, and pushes made with GITHUB_TOKEN do not trigger workflow runs. Confirmed empirically in the firmware repo, where the equivalent auto-commit ("Apply automatic changes") landed on beta and started no second run. Consequence worth stating: docs-only and tooling-only merges to beta will now also cut a pre-release. That is the intent -- beta is a moving pre-release channel, and constant version bumping there is explicitly acceptable. Co-authored-by: Henrik Olsson <henols@gmail.se> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>