Deliberately trigger CI workflows based on what files were changed#2213
Deliberately trigger CI workflows based on what files were changed#2213alamb merged 3 commits intoapache:masterfrom
Conversation
| name: arrow_flight | ||
|
|
||
|
|
||
| # trigger for all PRs that touch certain files and changes to master |
There was a problem hiding this comment.
This is the pattern:
on:
push:
branches:
- master
means "run on all changes to master"
on:
push:
branches:
- master
Means "run only when files in arrow/** arrow-flight/** or .github/** change"
| configuration-path: .github/workflows/dev_pr/labeler.yml | ||
| sync-labels: true | ||
|
|
||
| #- name: Checks if PR needs rebase |
Codecov Report
@@ Coverage Diff @@
## master #2213 +/- ##
=======================================
Coverage 82.56% 82.57%
=======================================
Files 239 239
Lines 62269 62269
=======================================
+ Hits 51415 51417 +2
+ Misses 10854 10852 -2
Help us with your feedback. Take ten seconds to tell us how you rate us. |
alamb
changed the title
|
🚀 |
|
Benchmark runs are scheduled for baseline = bc493d9 and contender = 8139f7b. 8139f7b is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
4 participants
Which issue does this PR close?
Closes #2149
This is the final part of the CI workflow I have planned under the aegis of that #2149 😓
Rationale for this change
Right now we run almost all CI checks for all PRs even those that make no code changes (changes to README, etc) or changes to some other crate (e.g. change in
arrow-flightcan't affectparquetyet we run all the parquet checks anyways)This increases PR times in two ways: 1 more checks need to complete and 2. we consume many github action builder minutes on useless tests, which increases the time spent waiting for a builder on the queue.
Of course, there is a real possibility that this change may miss running a CI check that causes master to fail -- but I think the improved PR speed and test specificity will make up for any such mishaps. We can also always go back to running all the tests on all PRs
What changes are included in this PR?
The basic idea is to run all tests on pushes to master (to keep master green) but only run the individual workflows on PRs that change files that could affect them.
Are there any user-facing changes?
No