.gitea/workflows/ci.yaml

@@ -113,6 +113,28 @@ jobs:
     if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
     runs-on: ubuntu-latest
     timeout-minutes: 2
+    # The workflow-level group above is keyed per-commit (github.sha) so
+    # unrelated commits' CI never blocks each other -- which also means two
+    # merges landing close together run two concurrent release-tag jobs, each
+    # force-pushing its OWN commit to v1. If the older one finishes last, v1
+    # regresses to a stale-but-green commit until the next merge corrects it.
+    #
+    # A job-level `concurrency:` is a second, independent group scoped to
+    # this job alone -- it does not replace the workflow-level one, it adds
+    # to it (confirmed by reading gitea's source at the v1.27.2 tag this
+    # instance runs: run-level and job-level concurrency are separate model
+    # fields, evaluated and enforced by separate functions --
+    # CancelPreviousJobsByRunConcurrency vs CancelPreviousJobsByJobConcurrency
+    # in models/actions/{run,run_job}.go -- not one overriding the other).
+    # A fixed, non-sha group name is what serialises across commits:
+    # `cancel-in-progress: false` keeps a running push from being interrupted
+    # by a newer one, and Gitea's default "single pending slot" behaviour
+    # (same as GitHub's) already supersedes any older QUEUED attempt with the
+    # newest one once the running job clears -- so this can delay v1 landing
+    # on the newest commit, never regress it to an older one.
+    concurrency:
+      group: release-tag-v1
+      cancel-in-progress: false
     # Requests write access from the run's built-in token (see README's
     # Versioning section for what's actually verified about it). Without
     # this the checkout below still succeeds -- it's the push that would be