Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow cancel-in-progress #2825

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
+4 −0
Open

Allow cancel-in-progress #2825

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7e97bbe
Allow cancel-in-progress except for `master`
franciszekjob Jan 6, 2025
e647a3f
Add `github.run_id` fallback
franciszekjob Jan 7, 2025
54e6c76
Merge branch 'master' into franciszekjob/cancel-previous-CI-runs
franciszekjob Jan 8, 2025
45ff8f1
Merge branch 'master' into franciszekjob/cancel-previous-CI-runs
franciszekjob Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,10 @@ on:
- master
workflow_dispatch:

concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: ${{ github.head_ref != 'master' }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

@franciszekjob franciszekjob Jan 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe keep it simple?

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

Copy link
Collaborator Author

@franciszekjob franciszekjob Jan 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will not cancel CI runs without a PR

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


jobs:
test-forge-unit-and-integration:
name: Test Forge / Unit and Integration Tests
Expand Down
Loading