-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Limit CI runs to pushes and pull requests on main repo #4305
Conversation
This is a follow-up to OpenMathLibgh-4271. At the moment, when a contributor pushes the latest `develop` to their own branch to bring their own fork in sync with `main`, or if they push another branch, this triggers 30 CI jobs to run. Most will complete silently and only burn CPU time unnecessarily. If there's a failure, this may result in unexpected failure notifications. And the AWS Graviton3 run won't complete at all and time out, since the Cirun hook will only work when triggered from the main repo.
The `group` expression ensures that the cancel-in-progress behavior is to only cancel if a new commit is pushed to the PR for which the job is running, not other PRs. This is a fairly standard snippet, used also in CI jobs for NumPy and other projects.
Thank you very much. I do not think it makes sense to expand the "only develop and release branches" bit to all CI jobs (if I understand correctly, this would e.g. disable CI on PRs against the present "riscv" branch). Preventing spurious runs outside the main repo would seem to make sense for the time-limited Cirrus service however. (I am not entirely sure how this would affect contributors who happen to have CI app bindings set up for their own fork in order to try PRs "in private" first - guess they would need to back out the change ?) |
Thanks Martin.
The intent was "all actively maintained branches", I didn't know about
This PR didn't affect Azure or Cirrus, so nothing changes there. I'll note that we do have custom logic to be able to skip runs on those better in NumPy/SciPy, but that's more cumbersome to deal with so I didn't bother to include that unless there's a real need. For GitHub Actions yes, the default behavior changes so if you want the old default back then you need to enable something as a contributor. In my experience, if I want to test something on my own fork before submitting a PR but after it works locally, it's for a specific CI config that I don't have locally. In those cases I'll insert a |
thanks, my comment was only in response to your question if it would be useful to apply similar restrictions to all the other CI jobs |
Two things we did that helped:
The logic for some of that has to be written in Starlark rather than YAML. https://github.com/scipy/scipy/blob/main/.cirrus.star may contain something of interest. Also, I spotted what looks like a quick win: the most expensive job is |
Thanks, that's certainly not intentional, just me forgetting that CMAKE won't instruct make and the MAKEFLAGS as output by getarch is useless unless applied manually. Maybe I'll look into caching the |
This is a follow-up to gh-4271.
develop
andrelease-**
branchesAt the moment, when a contributor pushes the latest
develop
to their own branch to bring their own fork in sync withmain
, or if they push another branch, this triggers 30 CI jobs to run. Most will complete silently and only burn CPU time unnecessarily. If there's a failure, this may result in unexpected failure notifications. And the AWS Graviton3 run won't complete at all and time out, since the Cirun hook will only work when triggered from the main repo.The
group
expression ensures that the cancel-in-progress behavior is to only cancel if a new commit is pushed to the PR for which the job is running, not other PRs. This is a fairly standard snippet, used also in CI jobs for NumPy and other projects.For the last change, triggering only on
develop
andrelease-**
branches, that could make sense to apply to all jobs as well (it's what we do in NumPy/SciPy). But I wasn't sure, that's more a personal preference. The difference is that that prevents the job from triggering to begin with, and hence it avoids the few seconds needed to start an instance, evaluate theif: github.repository ==
snippet, and shut down again. That process generates actions in the log on your own fork (note thatarm64 graviton cirun
is not visible here, because of the third commit):If you want me to add that to all CI jobs, please let me know @martin-frbg.