✍️ New post on GitHub Actions: avoid double runs of your workflows by using a better 'on' clause.
https://adamj.eu/tech/2025/05/14/github-actions-avoid-simple-on/
@adamchainz I'm going to push back against this, because best practice is to contribute via feature branches, and this prevents me from testing my code on CI *before* I open a PR.
My options, all impediments to contribution:
* don't run CI on my fork before opening a PR -- but I want to thoroughly test first before potentially wasting your time
* edit the workflow, then remember to revert before opening PR
* open PR on my fork first
* commit to my `main`
* not bother contributing
@hugovk @adamchainz Does `pull_request` still fire on a draft PR? I guess the maintainer still gets notified about a draft PR, which maybe defeats the purpose, but it seems like a fairly small fraction of people are running CI on their own forks. I basically never do that, I just make a draft PR early.
I guess this at least partially explains why ever PR I've ever gotten from you has been flawless and basically ready to merge from the get-go, though. 😅
@pganssle @adamchainz
Yes, `pull_request` it still fires on a draft PR:
https://github.com/hugovk/test/pull/97
Drafts do ping repo watchers, but not people in CODEOWNERS (like we have in CPython), only when marked ready for review.
Drafts also can't be merged until marked ready for review.
Yeah, most folk don't run CI on forks, it's even disabled by default, just a button click away. But CIs are so useful for us maintainers, let's make them useful for contributors too!
And thanks :)