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.

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

feat(ci): kill duplicate CI jobs on PRs #26945

Merged
merged 1 commit into from
Feb 1, 2024
Merged

feat(ci): kill duplicate CI jobs on PRs #26945

merged 1 commit into from
Feb 1, 2024

Conversation

mistercrunch
Copy link
Member

Taking over #25243, where @sebastianliebscher did great work and submitted this idea. I'm re-opening under a new PR to accelerate things a bit. I've been triggering lots and lots of CI jobs while working on docker and feeling guilty about my carbon footprint.

Here I grepped for workflows that have pull_request events and copy pasted the exact same snippet everywhere except for one place and that's the comment-triggered ephemeral builds, where I reference the issue number instead of the PR number. This should allow for someone to oops and retrigger the ephemeral build, and the lastest one should always land first, fixing potential race conditions

Taking over #25243, where
@sebastianliebscher did great work and submitted this idea. I'm
re-opening under a new PR to accelerate things a bit. I've been
triggering lots and lots of CI jobs while working on docker and feeling
guilty about my carbon footprint.

Here I grepped for workflows that have pull_request events and
copy pasted the exact same snippet everywhere except for one place and
that's the comment-triggered ephemeral builds, where I reference the
issue number instead of the PR number. This should allow for someone
to oops and retrigger the ephemeral build, and the lastest one should
always land first, fixing potential race conditions
Copy link

codecov bot commented Feb 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (959a5a5) 66.91% compared to head (a0a7fa9) 67.18%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #26945      +/-   ##
==========================================
+ Coverage   66.91%   67.18%   +0.27%     
==========================================
  Files        1900     1900              
  Lines       74320    74347      +27     
  Branches     8264     8264              
==========================================
+ Hits        49732    49952     +220     
+ Misses      22539    22346     -193     
  Partials     2049     2049              
Flag Coverage Δ
mysql 77.97% <ø> (?)
postgres 78.07% <ø> (?)
python 78.21% <ø> (+0.55%) ⬆️
sqlite 77.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -4,6 +4,11 @@ on:
issue_comment:
types: [created]

# cancel previous workflow jobs for PRs
concurrency:
group: ${{ github.workflow }}-${{ github.event.issue.number || github.run_id }}
Copy link
Member Author

Choose a reason for hiding this comment

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

this is the only edit that's different from the other ones, pointing to github.event.issue.number instead of github.event.pull_request.number

Copy link
Member

@rusackas rusackas left a comment

Choose a reason for hiding this comment

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

So excited about this... thanks @sebastianliebscher for kicking this off. This project will have a much smaller carbon footprint, and hopefully we'll see a lot less competition for resources among Apache projects :)

@rusackas
Copy link
Member

rusackas commented Feb 1, 2024

Actually... if this does solve our problem with double-runs (like pushing those package lock files) then we can solve another DevEx problem in a similar way... we can run pre-commit and lint-fix on PRs and push the changes, which would probably un-block PRs where contributors didn't know they need to do that.

@rusackas rusackas merged commit 26e330e into master Feb 1, 2024
35 checks passed
@mistercrunch
Copy link
Member Author

mistercrunch commented Feb 1, 2024

we'll see a lot less competition for resources among Apache projects

There's an incentive for us to go and do a similar PR in Apache projects that are using a significant amount of resources :)
@rusackas do we know of a way to monitor resources we compete for at the org (apache) level? Wouldn't be crazy to submit a similar PR against say apache/kafka if we knew they're hogging a significant part of the resource pool...

sfirke pushed a commit to sfirke/superset that referenced this pull request Mar 22, 2024
@rusackas rusackas deleted the kill_dups branch April 16, 2024 16:53
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 4.0.0 labels Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/M 🚢 4.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants