2026-09-22 23:13:00 +00:00
1 changed files with 22 additions and 0 deletions
@@ -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