ci: one build per branch, newer push cancels the older run (#90)

[compot-dev]

Closes #90.

Workflow-level concurrency grouped by event and ref, cancel-in-progress for pushes and pull requests:

• On basic / v2 a newer merge cancels the run of the older one, so the latest release and the Telegram post always carry the build of the newest commit, not of whichever run finished last.
• Working branches and PRs: superseded runs are cancelled too (saves CI minutes).
• Manual runs (workflow_dispatch, optionally with commit_hash) get a group per run: never cancelled by a push and never replaced by another manual run.

Decision on the second question of #90: every merge into basic / v2 keeps publishing to latest (testers use it, see LABORATORY.md); only the race is removed. A manual run with an old commit_hash still publishes that build on purpose.

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Queued manual builds get dropped ✓ Resolved

Description

The workflow assigns every manual dispatch for a ref to one concurrency group while disabling
cancellation of the running job. GitHub Actions retains only one pending run per group, so a later
manual dispatch can replace an earlier pending build instead of letting all manual builds queue
behind one another.

Code

.github/workflows/build.yml[R16-17]

+  group: build-${{ github.event_name }}-${{ github.ref }}
+  cancel-in-progress: ${{ github.event_name != 'workflow_dispatch' }}

Evidence

The workflow declares manual dispatches at the top level and groups them using the event name and
ref. Therefore repeated manual dispatches for the same ref share the same concurrency group, while
the false expression only disables cancellation of an active run and does not create an unlimited
pending queue.

.github/workflows/build.yml[5-10]
.github/workflows/build.yml[15-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Manual `workflow_dispatch` runs for the same ref share one concurrency group, and `cancel-in-progress: false` only protects the currently running run; pending manual runs can still be replaced by newer pending runs.
## Fix Focus Areas
- .github/workflows/build.yml[15-17]
## Recommended Fix
Do not rely on workflow-level concurrency to provide an unlimited FIFO queue for manual runs. Either exclude `workflow_dispatch` runs from this concurrency group so every manual request is retained, or implement an explicit durable queue if manual runs must execute serially; keep push and pull-request runs grouped with cancellation enabled.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn these tips off under Display > Comment parts

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[compot-dev]

Qodo: Queued manual builds get dropped — accepted and fixed: every manual run now has its own concurrency group (manual-<run_id>), so manual runs neither cancel nor replace each other.

/review

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Qodo: Queued manual builds get dropped — accepted and fixed: every manual run now has its own concurrency group (manual-<run_id>), so manual runs neither cancel nor replace each other.

/review

The change addresses finding 1: each manual dispatch now uses a unique manual-${{ github.run_id }} concurrency group, so manual runs will not cancel or replace one another. /review isn’t available in this deployment, so I can’t trigger a fresh review here; I can still inspect the diff or explain the concurrency behavior.

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit feca2d2