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.

[Naxdy]

Sounds good. Feel free to ping / DM on discord if you want me to test something, or need something else. I've been running this for a while on my instance already.

[Zettat123]

@ChristopherHX Sorry for the late reply, as I was busy with other work last month. Thank you for the improvements and bug fixes to this PR. Please feel free to update the code. I will also check if there are still issues with this PR.

[ChristopherHX]

Hi,

No problem, once we both agree this is finished and can be merged I approve.

Good that you already looked at the cancellation problem.

I still think about if my code removal is correct or not in sense of not only let existing tests pass.

• 9bba25e
• 2e6032a

I had another behavior difference
If we do not have cancel in progress

• GitHub Actions cancells all earlier blocked runs/jobs (only inprogress are kept if cancel-in-progress is false)
• This PR queues up and runs every Run one by one

Would we want to add a custom boolean to implement both behaviors?

concurrency:
  cancel-pending: true # default true for GitHub Actions Compat, false for current implementation

Would we want to keep the behavior difference and document it?

[Zettat123]

I still think about if my code removal is correct or not in sense of not only let existing tests pass.

• 9bba25e
• 2e6032a

I think these changes look good. Thanks for simplifying the code.

I had another behavior difference If we do not have cancel in progress

• GitHub Actions cancells all earlier blocked runs/jobs (only inprogress are kept if cancel-in-progress is false)
• This PR queues up and runs every Run one by one

Yes. I noticed the behavior difference between GitHub actions and my implementation. I think for now we can use GitHub's logic. And in the future, we can add the cancel-pending option as a new feature. If we agree to this solution, I would like to modify the current logic (or you can push your changes if you have done :) ).

[ChristopherHX]

In d5f6c44 I have implemented my last TODO that does not require changes to gitea/act.

This now works good for me

---

My last open discussion point is this one, since this is related to our database structure. The functionality to allow the shorten syntax of concurrency is ok for me to defer.

If we would see the following valid GitHub Action snipped

concurrency: |-
  ${{ fromjson('{
    "group": "somegroup",
    "cancel-in-progress": true
  }') }}

concurrency: |-
  ${{ fromjson(vars.CONCURRENCY_GROUP_OBJ) }}

How do we pass this to Gitea via RawConcurrency?

---

My current idea would be adding some boilerplate expression so this is transparent for the current implementation e.g. store

where fromjson(vars.CONCURRENCY_GROUP_OBJ) is the original expression

RawGroup: "${{ !fromjson(vars.CONCURRENCY_GROUP_OBJ).group && fromjson(vars.CONCURRENCY_GROUP_OBJ) || fromjson(vars.CONCURRENCY_GROUP_OBJ).group }}"

While this does feel a bit bad, we need to copy paste a lot to make this work without side effects

---

On the other hand, Could we just store RawConcurrency as json/yaml? Instead of splitting it before evaluation.

EDIT
I prepared a long time ago ee.EvaluateYamlNode(...) for this scenario.

[Zettat123]

My last open discussion point is this one, since this is related to our database structure. The functionality to allow the shorten syntax of concurrency is ok for me to defer.

I would prefer the second solution:

On the other hand, Could we just store RawConcurrency as json/yaml? Instead of splitting it before evaluation.

In this way, we only need a RawConcurrency to store the raw content of concurrency and we can remove RawConcurrencyGroup and RawConcurrencyCancel. To support this, should we also improve EvaluateConcurrency to allow it to parse RawConcurrency in different formats?

I prepared a long time ago ee.EvaluateYamlNode(...) for this scenario.

If you have completed the code, please feel free to push your changes.

[ChristopherHX]

I will look into implementing the second solution.

To support this, should we also improve EvaluateConcurrency to allow it to parse RawConcurrency in different formats?

Yes this is going to be required together with fixing parsing the workflow to support both formats.

Change to act, seems like I can make this merge as soon as possible and this PR does not have to wait

• https://gitea.com/gitea/act/pulls/139

[ChristopherHX]

I am somewhat confused, after my first attempt 796d2c1 to use a single RawConcurrency entry gitea feels to be slow to queue...

I didn't expected such a slowdown via yaml.Marshal and yaml.Unmarshal.

I will revert and test again to check if this is unrelated...