Only run CI on pushes to main/master and pull requests #7883
Conversation
Currently, when a maintainer opens a pull request from a branch in the typeshed repository (instead of a fork), CI is run twice: once for the PR and once for the push. This not only wastes CI minutes (and it seems we're running into some limits lately), but also makes CI output twice as large and more difficult to process. The disadvantage is that a PR needs to be opened to run CI. Alternatively, CI can be triggered manually.
|
Example: #7882 |
Oh, how do you do that? I wasn't aware (and I've found it useful in the past to run CI on a branch, prior to opening a PR, though it's not my normal workflow). As well as this, we can also consider only running |
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Instructions here, for future reference: https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow. It's pretty easy, so I'm fine with this change. |
| @@ -3,6 +3,9 @@ name: Test | |||
| on: | |||
| workflow_dispatch: | |||
| push: | |||
| branches: | |||
| - main | |||
There was a problem hiding this comment.
We currently don't have a main branch, so this is redundant. If we some day decide to rename master to main, we'll have to grep for master anyway.
Currently, when a maintainer opens a pull request from a branch in the
typeshed repository (instead of a fork), CI is run twice: once for the
PR and once for the push. This not only wastes CI minutes (and it seems
we're running into some limits lately), but also makes CI output twice
as large and more difficult to process.
The disadvantage is that a PR needs to be opened to run CI.
Alternatively, CI can be triggered manually.