Support Actions concurrency syntax

[Zettat123]

Fix #24769
Fix #32662
Fix #33260

Depends on https://gitea.com/gitea/act/pulls/124

• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#concurrency

⚠️ BREAKING ⚠️

This PR removes the auto-cancellation feature added by #25716. Users need to manually add concurrency to workflows to control concurrent workflows or jobs.

[lunny]

I created a test workflow file like this

on:
  push:
    branches:
      - main

concurrency:
  group: example-group
  cancel-in-progress: true

jobs:
  job-1:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'test1' && sleep 60

But it seems new run task will not cancel the old one.

[lunny]

For pull request jobs, maybe the previous job should be cancelled by default even if there is not concurrency statement.

[Zettat123]

I created a test workflow file like this

on:
  push:
    branches:
      - main

concurrency:
  group: example-group
  cancel-in-progress: true

jobs:
  job-1:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'test1' && sleep 60

But it seems new run task will not cancel the old one.

Good catch. There was a bug when checking workflow-level concurrency groups. Now it has been fixed.

[ChristopherHX]

I just tried this, with workflow

on: push
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        no:
        - 1
        - 2
        - 3
        - 4
        - 5
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Run tests
      run: |
        echo ${{ github.run_id }} > "/tmp/test.txt"
    - uses: christopherhx/gitea-upload-artifact@v4
      with:
        path: test.txt
        name: test

• Without any connected act_runner I pushed this via automation.
• pushed a second file
• Connect a single act_runner
• All good first workflow cancelled, last push succeeded 👍
• Now rerun all jobs of the previously cancelled run
• Rerun all jobs latest previously successful run (directly after the other rerun)
• latest previously successful rerun is cancelled and the rerun of "previously cancelled" succeeded

I expected the same result as on initial push, same order opposite behavior

Maybe you could provide me some insights, or I am going to debug this myself and share you my findings

What works good so far

• Pushing two workflows without concurrency, I like this

[ChristopherHX]

This code is cancelling implicitly a newer (re)run while a task is picked by an older (re)run and seems to be the cause for the behavior I described just before

I would expect only scheduling a job updates concurrency, since I am still using GitHub Actions side by side

Rerun all jobs didn't cancel the older run, which is already an error state.

[ChristopherHX]

Rerun all jobs didn't cancel the older run, which is already an error state.

Status fixed, by respecting workflow concurrency in rerun all jobs.

[ChristopherHX]

I would expect that job concurrency key cancels equal workflow concurrency if defined on job level.

Based on my experience workflow and job concurrency use the same pool of concurrency keys. (deadlock handling required)

and CancelPreviousJobsByRunConcurrency to not be called here (EDIT 2 idk how this PR currently works, might break everything if not replaced)

e.g.

jobs:
  _:
    concurrency: test

cancels workflow

concurrency: test

In response of the unexpected behavior I have seen

EDIT
If we add an optional job / string parameter to CancelPreviousJobsByRunConcurrency , so the concurrency group of the job can be provided to replace the run concurrency key would fulfill my expectation, I guess.

[seriouz]

Any news on this? Is this still planed for 1.25.0?

[ChristopherHX]

@Zettat123 I would try to fix my findings here and resolve the conflicts, but I have no access to this Pullrequest (Maintainer with read only access).

Allowing to queue up Workflows again is very nice, since I am not in favor of auto concurrency of length 1.

For own CI feedback I need create a new (draft) PR including all commits from here.

Then there are multiple options

• I create a PR against the PR branch
• You push my changes to your branch
• We continue discussing on my followup PR

Thank you for all your work on this so far :).

[wxiaoguang]

If you'd like to work with others' PRs often, maybe you can ask @go-gitea/technical-oversight-committee or some core members like @lunny to apply a merger's access, then you can edit PRs directly

[ChristopherHX]

I would expect this to happen < 5 times per year. I actually only applied as maintainer due to work with others' PRs. I will ask formally in discord.