Skip to content

Configure GitHub workflows to use concurrency cancel-in-progress for pull requests#8171

Open
apupier wants to merge 1 commit into
apache:masterfrom
apupier:addConcurrencyCancelInprogressForPRGitHubWorkflows
Open

Configure GitHub workflows to use concurrency cancel-in-progress for pull requests#8171
apupier wants to merge 1 commit into
apache:masterfrom
apupier:addConcurrencyCancelInprogressForPRGitHubWorkflows

Conversation

@apupier

@apupier apupier commented Jun 8, 2026

Copy link
Copy Markdown

see recommended best practices at Apache
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=GitHub+Actions+Recommended+Practices

Purpose

Configure GitHub workflows to use concurrency cancel-in-progress for pull requests. it will allow to reduce workloads of GitHub workflows for Apache organization

Tests

@apupier apupier changed the title Configure GitHub workflows to use concurrency cancel-in-progress for Configure GitHub workflows to use concurrency cancel-in-progress for pull requests Jun 8, 2026
@apupier apupier force-pushed the addConcurrencyCancelInprogressForPRGitHubWorkflows branch from 637b19c to b210f28 Compare June 8, 2026 13:04
@apupier

apupier commented Jun 15, 2026

Copy link
Copy Markdown
Author

the canceled job (marking the PR as failure) is unrelated to the PR change.

Any chance to have it reviewed please?
Apache pool of GitHub actions runners is shared across all Apache projects. During the last weeks, the limits was often reached causing jobs to be queued. The intent of this PR is to reduce the load to limit the queue time.

@apupier

apupier commented Jun 16, 2026

Copy link
Copy Markdown
Author

Anyone can review please?

Currently there are several jobs in the queue and just for last few hours and looking at a single PR checks we could have saved several hours of compute time (see https://github.com/apache/paimon/actions/workflows/e2e-tests-flink-2.x-jdk11.yml and look for same branch triggered several times in few minutes between them)

@apupier

apupier commented Jun 16, 2026

Copy link
Copy Markdown
Author

trying by mentioning some of the most active contributors to have more chance that it is noticed as i think that given it is impacting a bit all Apache projects using GitHub actions, this is important enough:
@JingsongLi @XiaoHongbo-Hope @leaves12138

@XiaoHongbo-Hope

Copy link
Copy Markdown
Contributor

Thanks for filling in the missing concurrency configs!

The concurrency pattern is inconsistent across this PR: utitcase-jdk11.yml uses cancel-in-progress: true while the other 4 files use cancel-in-progress: ${{ github.event_name == 'pull_request' }}. Also, e2e-tests-flink-1.x.yml already had a
working concurrency block

@apupier

apupier commented Jun 17, 2026

Copy link
Copy Markdown
Author

The concurrency pattern is inconsistent across this PR: utitcase-jdk11.yml uses cancel-in-progress: true while the other 4 files use cancel-in-progress: ${{ github.event_name == 'pull_request' }}

When the workflow can be triggered only by pull_request event, I proposed a simplified value for cancel-in-progress.
Do you prefer to align to use the same concurrency pattern or keep as proposed?

Also, e2e-tests-flink-1.x.yml already had a
working concurrency block

this one I changed it to align with other concurrency declaration.
Do you prefer to keep this one not aligned with other concurrency pattern or to align it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants