fix(ci): serialize build-macos release runs so the v* tag build is not dropped (VA-136) #143

Merged

longjacksonle merged 1 commit from fix/VA-136-build-macos-concurrency into main

2026-07-15 18:10:01 +02:00

longjacksonle commented

2026-07-15 17:51:38 +02:00

Owner

Fixes VA-136: build-macos.yml drops the v* tag build at release time when the single macOS runner is busy, so macOS misses the pinned X.Y.Z and stable channels.

Root cause (confirmed on the running Forgejo 14.0.2)

On a release, two push events fire near-simultaneously and both match build-macos.yml:

merge commit onto main (branch context) -> publishes latest
v* tag pushed by create-release.yml (tag context) -> publishes pinned X.Y.Z + stable

With no concurrency block, the Forgejo Actions reference states it auto-manages on.push runs by cancelling any other invocation of the same workflow when a new event arrives. On the single self-hosted macOS runner one of the two near-simultaneous runs gets cancelled, so v0.4.0 macOS published only latest (run 558, branch) with no tag run at all, while the multi-slot Linux/Windows container runners published pinned + stable normally (runs 563/564).

Fix

Add a fixed workflow-level concurrency group with cancel-in-progress: false:

concurrency:
  group: build-macos
  cancel-in-progress: false

Per the Forgejo Actions reference, cancel-in-progress: false with a group replaces the default auto-cancellation with sequential queuing: any previous invocation in the group completes before the newer one runs. So at release the branch run finishes (publishes latest), then the queued tag run executes (publishes pinned + stable). A fixed group serializes all macOS builds, which is harmless since there is only one macOS runner.

Scope

Only build-macos.yml changes. The Linux/Windows pipelines run on multi-slot container runners, did not exhibit the drop, and are left unchanged.
No behavior change for non-release main pushes beyond serialization (macOS builds already could not parallelize on one runner).

Validation

Verified at the semantic level against the running Forgejo (14.0.2): its Actions reference documents both the auto-cancel default that caused the drop and the cancel-in-progress: false sequential-queue behavior that fixes it.
YAML validated (parses; concurrency group + cancel-in-progress: false present; job intact).
Full runtime confirmation lands on the next tagged release: both a branch-context and a tag-context build-macos run should appear and complete, publishing latest plus pinned X.Y.Z + stable. (This workflow is push/tag-triggered, so it does not run on this feature-branch PR.)

🤖 Generated with Claude Code

Fixes VA-136: build-macos.yml drops the `v*` tag build at release time when the single macOS runner is busy, so macOS misses the pinned `X.Y.Z` and `stable` channels. ## Root cause (confirmed on the running Forgejo 14.0.2) On a release, two push events fire near-simultaneously and both match build-macos.yml: - merge commit onto main (branch context) -> publishes `latest` - `v*` tag pushed by create-release.yml (tag context) -> publishes pinned `X.Y.Z` + `stable` With no `concurrency` block, the Forgejo Actions reference states it auto-manages `on.push` runs by cancelling any other invocation of the same workflow when a new event arrives. On the single self-hosted macOS runner one of the two near-simultaneous runs gets cancelled, so v0.4.0 macOS published only `latest` (run 558, branch) with no tag run at all, while the multi-slot Linux/Windows container runners published pinned + stable normally (runs 563/564). ## Fix Add a fixed workflow-level concurrency group with `cancel-in-progress: false`: ```yaml concurrency: group: build-macos cancel-in-progress: false ``` Per the [Forgejo Actions reference](https://forgejo.org/docs/latest/user/actions/reference/), `cancel-in-progress: false` with a group replaces the default auto-cancellation with sequential queuing: any previous invocation in the group completes before the newer one runs. So at release the branch run finishes (publishes `latest`), then the queued tag run executes (publishes pinned + stable). A fixed group serializes all macOS builds, which is harmless since there is only one macOS runner. ## Scope - Only build-macos.yml changes. The Linux/Windows pipelines run on multi-slot container runners, did not exhibit the drop, and are left unchanged. - No behavior change for non-release main pushes beyond serialization (macOS builds already could not parallelize on one runner). ## Validation - Verified at the semantic level against the running Forgejo (14.0.2): its Actions reference documents both the auto-cancel default that caused the drop and the `cancel-in-progress: false` sequential-queue behavior that fixes it. - YAML validated (parses; concurrency group + `cancel-in-progress: false` present; job intact). - Full runtime confirmation lands on the next tagged release: both a branch-context and a tag-context build-macos run should appear and complete, publishing `latest` plus pinned `X.Y.Z` + `stable`. (This workflow is push/tag-triggered, so it does not run on this feature-branch PR.) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

longjacksonle added 1 commit

2026-07-15 17:51:38 +02:00

fix(ci): serialize build-macos release runs so the v* tag build is not dropped (VA-136)

Check / fmt + clippy + tests (pull_request) Successful in 14m28s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

3135392545

On a release, two push events fire near-simultaneously: the merge commit onto main (branch context, publishes `latest`) and the `v*` tag that create-release.yml pushes (tag context, publishes the pinned `X.Y.Z` + `stable` channels). Both match build-macos.yml. With no concurrency block, Forgejo auto-manages `on.push` runs by cancelling any other invocation of the same workflow when a new event arrives. On the single self-hosted macOS runner that cancelled the tag build, so v0.4.0 macOS published only `latest` (run 558, branch) and never produced a tag run, while the multi-slot Linux/Windows container runners published pinned + stable normally (runs 563/564).

Add a fixed workflow-level concurrency group with `cancel-in-progress: false`. Per the Forgejo 14 Actions reference this replaces the default auto-cancellation with sequential queuing: the earlier (branch) run completes, then the queued (tag) run executes, so both channel sets publish. A fixed group serializes all macOS builds, which is harmless given there is a single macOS runner. Scoped to build-macos.yml; the container-runner pipelines were unaffected and are left unchanged.

Runtime validation lands on the next tagged release (the branch and tag build-macos runs should both appear and complete, publishing latest plus pinned + stable). Confirmed against the running Forgejo (14.0.2): the reference documents both the auto-cancel default that caused the drop and the cancel-in-progress:false sequential-queue behavior that fixes it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LYb1fkK32XQdwkGkStxXR9
Signed-off-by: longjacksonle <longjacksonle@gmail.com>