[Actions] Support concurrency syntax

[lunny]

Feature Description

simple:

concurrency:
  group: container-release

advanced:

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

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

[silverwind]

Edited to also include an advanced example, it's from our current github actions workflows and serves the purpose of cancelling duplicate runs for the same PR.

[jimafisk]

Being able to cancel in-progress builds when a new build comes in would be super helpful for my project! Would love to see this implemented ❤️

Thanks for all your hard work team!

[denyskon]

Being able to cancel in-progress builds when a new build comes in would be super helpful for my project! Would love to see this implemented ❤️

Thanks for all your hard work team!

For push events, the auto-cancellation already works on 1.21, you just don't have control over it AFAIK

[jimafisk]

For push events, the auto-cancellation already works on 1.21, you just don't have control over it AFAIK

Oh that's very interesting, I believe this is the related PR for reference: #25716

Thanks for calling this out @denyskon, you have the best tips!

My understanding is this works off gitea.ref (the branch or tag that triggered the workflow run). I'm adding changes via the API using the /repos/{owner}/{repo}/contents/{filepath} endpoint and it seems to be queuing the actions and completing them one at a time. Do you know if cancellation is possible in this workflow? (I think I'm having trouble because I'm on v1.20.5, I'll upgrade to v1.21 and give it another shot)

Edit: I tested with v1.21.0 that was released yesterday and this works great out of the box. Thank you!

[calvinbui]

@wolfogre can I request a way to disable the default auto-cancellation (#25716 (comment))

I have a git repo with multiple ansible playbooks and my CI workflow only deploys whichever one was modified in the commit it's running on.

I use renovate to merge a lot of updates and it'll just cancel the deployments midway through. It doesn't even trigger the fail notification step I have as the job is completely gone.

[wolfogre]

@calvinbui Sorry I don't have plans to implement the suggestion I left at #25716 (comment) , maybe others can help.

However, I don't thinks auto-cancellation is a bad idea in your case. What if #522 finisehed first, and then #521 continued deploying (somethink slowed it down) with an older version?

[calvinbui]

@calvinbui Sorry I don't have plans to implement the suggestion I left at #25716 (comment) , maybe others can help.

Can you clarify if you mean Gitea won't implement this or you won't be working on it?

However, I don't thinks auto-cancellation is a bad idea in your case. What if #522 finisehed first, and then #521 continued deploying (somethink slowed it down) with an older version?

In my case, that would be fine. one is updating a tool called notify_push and the other is updating another tool called outline. They are separate files which I am handling. But yes, I understand the conundrem you're explaining.

[wolfogre]

Can you clarify if you mean Gitea won't implement this or you won't be working on it?

Sorry for the confusion. I meant to say that I don't have any plans to do it because I'm busy with other things (I thought you were asking me when you mentioned me). I cannot represent Gitea or the Gitea maintainers team. That's why I said "maybe others can help".

[dh-harald]

I'm still struggling with autocancellation.
I've a repository with various dockerfiles, updated by renovatebot.
The pipeline is based on modified directories (i'll add dynamic matrix, if will implemented), so if a Dockerfile changed, it will build a new image. Today morning there was a change in 2 base images, renovate bot created two commits, therefore the first one was instantly cancelled.
I badly need to opt out auto-cancel to avoid this kind of problems

[schlamar]

I created a new issue for opt-out from auto-cancelling: #32662

This should be fixed separately from concurrency feature.