Allow cancel-in-progress

[franciszekjob]

Closes #

Introduced changes

This configuration enables the cancellation of previous workflow runs when a new commit is pushed to the same branch, optimizing CI resource usage (except for master)

Checklist

• Linked relevant issue
• Updated relevant documentation
• Added relevant tests
• Performed self-review of the code
• Added changes to CHANGELOG.md

[cptartur]

https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs#example-using-a-fallback-value

For example, github.head_ref is only defined on pull_request events.

Won't this cause problems?

[franciszekjob]

Right, it looks like we should add github.run_id as fallback

[kkawula]

github.run_id is different for each workflow run, so grouping won;t be proper

[ddoktorski]

If github.head_ref is only defined for a pull_request event, isn't this condition always true? Should we use github.ref_name or something else here?

[cptartur]

Perhaps ${{ !!github.head_ref }} would work?

[franciszekjob]

It looks to me such configuration will be sufficient:

concurrency:
  group: ${{ github.head_ref || github.ref_name }}
  cancel-in-progress: ${{ (github.head_ref && github.head_ref != 'master') || (github.ref_name && github.ref_name != 'master') }}

Workflow will be canceled in two cases:

• github.head_ref is defined (PR) and it's not master
• github.ref_name is defined (commits on branch) and it's not master
  Workflow won't be cancelled if action applies to master. And basically that's all we need.

Wdyt @ddoktorski @cptartur ?

[cptartur]

I think it should be okay. Though if head_ref is pretty much only defined for pull requests, shouldn't it be sufficient to just check if it's defined?

[ddoktorski]

Maybe keep it simple?

cancel-in-progress: ${{ github.event_name == 'pull_request' }}

[franciszekjob]

I think it should be okay. Though if head_ref is pretty much only defined for pull requests, shouldn't it be sufficient to just check if it's defined?

Maybe keep it simple?

cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Checking only if head_ref or github.event_name == 'pull_request' will not cancel CI runs without a PR so I think we should leave both. @cptartur @ddoktorski

[ddoktorski]

will not cancel CI runs without a PR

What are other cases in which we want to cancel it other than PRs?

[franciszekjob]

For instance when someone doesn't open a PR but has a branch and pushes commits to it.

[kkawula]

It looks to me such configuration will be sufficient:

concurrency:
  group: ${{ github.head_ref || github.ref_name }}
  cancel-in-progress: ${{ (github.head_ref && github.head_ref != 'master') || (github.ref_name && github.ref_name != 'master') }}

Workflow will be canceled in two cases:

• github.head_ref is defined (PR) and it's not master
• github.ref_name is defined (commits on branch) and it's not master
  Workflow won't be cancelled if action applies to master. And basically that's all we need.

Wdyt @ddoktorski @cptartur ?

I suppose that we can skip head_ref because there will always be only one workflow in this group (triggered by pr), group: ${{ github.ref_name }} should be sufficient

[ddoktorski]

For instance when someone doesn't open a PR but has a branch and pushes commits to it.

CI doesn't run in such cases anyway

[cptartur]

See my comment