added workflow concurrency to optimize runner usage#3189
Conversation
There was a problem hiding this comment.
Pull request overview
Adds GitHub Actions workflow-level concurrency controls to reduce wasted CI capacity by canceling superseded workflow runs for pull requests (where rapid successive commits can otherwise trigger multiple long-running runs).
Changes:
- Add a
concurrencyblock toux-tests.ymlto cancel in-progress runs on PR updates. - Add a
concurrencyblock tofull-stack-test.ymlto cancel in-progress runs on PR updates.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/workflows/ux-tests.yml | Introduces workflow concurrency grouping and PR-only cancellation to avoid redundant heavy integration runs. |
| .github/workflows/full-stack-test.yml | Introduces workflow concurrency grouping and PR-only cancellation to avoid redundant full-stack runs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Greptile SummaryThis PR adds a
Confidence Score: 4/5Safe to merge — the concurrency blocks are correctly scoped and will not affect master builds or manually dispatched runs. Both workflows correctly distinguish push-to-master (unique SHA group, no cancellation) from pull-request (shared ref group, cancellation enabled). The only trade-off is that ux-tests.yml groups the fast unit-tests job under the same concurrency key as the heavy matrix jobs, meaning rapid PR commits can leave unit-test results missing. This is a minor quality concern, not a correctness issue. ux-tests.yml — the workflow-level concurrency key covers both the lightweight unit-tests and the heavy matrix ux-tests jobs together. Important Files Changed
Reviews (1): Last reviewed commit: "added workflow concurrency to optimize r..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event_name == 'push' && github.sha || github.ref }} | ||
| cancel-in-progress: ${{ github.event_name == 'pull_request' }} |
There was a problem hiding this comment.
Because concurrency is applied at the workflow level, the lightweight unit-tests job (~30 s, no infrastructure) is cancelled together with the expensive matrix ux-tests jobs whenever a new PR commit arrives. In practice this means you can push a second commit and never see a unit-test result for the first one, which can hide quick feedback. Splitting unit-tests into its own workflow (or moving it to a dedicated file that doesn't have this concurrency block) would let it always run to completion while still cancelling the heavy ux-tests on outdated commits.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3189 +/- ##
=========================================
Coverage ? 28.29%
=========================================
Files ? 381
Lines ? 52343
Branches ? 9238
=========================================
Hits ? 14808
Misses ? 36597
Partials ? 938 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
PR Type
Summary
This PR adds
concurrencycontrols to theux-tests.ymlandfull-stack-test.ymlGitHub Actions workflows.Currently, if anyone pushes multiple commits to a PR very quick, GitHub Actions triggers workflows for every single commit. Since these workflows spin up heavy infrastructure like minikube, Tilt it comsumes a large amout of time.
So, This PR adds a
concurrencyblock to the longer workflows: