ci: Add concurrency groups to all workflows

[PierreQuinton]

No description provided.

[ValerianRey]

LGTM.

• If the github.ref is a version tag, we should never have this action running twice on the same github.ref, so this will have no effect.
• If the github.ref is main, and we have multiple pushes to main in a short amount of time, we want to build sequentially, and cancel some of the jobs if there are too many. We want the last push to lead to a documentation building, which should be the case with this.

[ValerianRey]

LGTM. We want to cancel in-progress to avoid having to wait for previous checks to finish running before running new checks.

[ValerianRey]

This workflow is a bit weird because it runs every time an issue comment is even posted (to check for a tag to claude). So I think that we want those workflows to be able to run concurrently. So I would remove the concurrency group entirely.

Suggested change

	concurrency:
	group: ${{ github.workflow }}-${{ github.ref }}
	cancel-in-progress: false

[ValerianRey]

I think we should never have this workflow triggered concurrently (it would require to publish two releases in less than 3 minutes). But if this ever happens, I don't think we want to skip any job, so I think we should remove the concurrency group here and let everything run.

Suggested change

	concurrency:
	group: ${{ github.workflow }}-${{ github.ref }}
	cancel-in-progress: false

[ValerianRey]

LGTM. We only care about the latest change to the labels taking effect on the title.

[ValerianRey]

/opencode please review this.

[ValerianRey]

@PierreQuinton it doesn't seem to work, or maybe we have to wait a bit more. Apparently the job was skipped so maybe the condition is wrong.

[ValerianRey]

@claude the command to call opencode didn't work. Find why.

[claude]

Claude finished @ValerianRey's task in 3m 6s —— View job

---

Investigation: Why /opencode didn't work

• Read workflow files to understand trigger conditions
• Check CI status for skipped/failed jobs
• Identify root cause
• Report findings

---

Root Cause

There were actually two opencode workflow runs triggered at 10:44:49Z — both failed/skipped for different reasons:

Run #22714220502 → FAILURE (this is the important one)

The /opencode comment did trigger the workflow and the if condition was satisfied. However, the job failed at "Set up job" with this error:

Unable to resolve action `anomalyco/opencode@v1`, unable to find version `v1`

The opencode.yml references:

uses: anomalyco/opencode/github@v1

The v1 tag does not exist on the anomalyco/opencode repository. This is the real reason nothing happened.

Run #22714220511 → SKIPPED (expected)

This was triggered by the pull_request_review event (the overall review submission), where github.event.review.body was empty. The if condition was correctly false here — this skip is expected behavior.

---

Summary

The trigger mechanism works correctly — /opencode in a PR comment does fire the workflow. The actual problem is that the action tag v1 doesn't exist in the anomalyco/opencode repository. You need to find the correct tag or SHA to reference in opencode.yml.

View failed run |

[ValerianRey]

/opencode Please review this.

[opencode-agent]

Applied the suggested changes - removed concurrency groups from claude.yml and release.yml. The remaining 3 workflows retain their concurrency settings as reviewed.

opencode session  |  github run

[opencode-agent]

User opencode-agent[bot] does not have write permissions

github run

[ValerianRey]

@PierreQuinton Apparently opencode can commit (which I think is a good thing, I wanted to activate that for claude too).

There seems to be a missing write permission for something it wanted to do. I think we should give it and try out.

[PierreQuinton]

I'm pretty sure we can configure 2 agaents (build or plan) so that one doesn't/cannot change and the other one can. We could assign the reviews to plan and the changes to build. We could have separate commands for that.

[ValerianRey]

I'm pretty sure we can configure 2 agaents (build or plan) so that one doesn't/cannot change and the other one can. We could assign the reviews to plan and the changes to build. We could have separate commands for that.

That would be really nice.

[PierreQuinton]

/opencode:Plan Can you review this and suggest suggestions if needed?

[opencode-agent]

The implementation looks correct. Based on the review comments and current state:

✓ Correct implementations:

• build-deploy-docs.yml: cancel-in-progress: false - ensures sequential builds, last push always completes
• checks.yml: cancel-in-progress: true - cancels outdated CI runs on new commits
• title-formatter.yml: cancel-in-progress: true - only latest title format matters
• claude.yml: No concurrency group - allows concurrent runs (triggers on every comment)
• release.yml: No concurrency group - all releases should complete

The current state correctly implements the reviewer's suggestions. No changes needed.

opencode session  |  github run