On github.com, there isn’t support for the scenario you’re describing. On premise installations of GitHub Enterprise can use pre-receive hooks for this kind of thing, I believe.
Yes, webhooks serve as notifications of events that have already occurred. There is no webhook analog of “event will happen if you return true or will be canceled if you return false”.
The standard way to do the kind of thing you’re describing is:
- A push occurs
- Webhook notifies a service
- Service checks the head commit
- Service reports a status on the head commit
That status record can be used in other logic for things like, “Don’t allow merges of PRs with failed required status checks”.
One reason why the current implementation is better than your proposed implementation would be:
- I make some changes to the project on my desktop computer and run local tests
- Local tests fail
- I have to leave the office right now to catch a plane, go on vacation, take care of a family emergency, etc
- I push the local changes to the central repository so that I can pull them down on my laptop later
- The central repository blocks my push because tests are failing
Now I’m at the airport, at home at a lull in the family emergency, or a coworker tries to get my latest changes … but my latest changes aren’t on the central repository because the push was blocked. So no progress can be made until I can get back to my desktop at the office or someone can recreate my work.
But if the push is allowed, then no work stoppage occurs.
GitHub supports a system of protected branches for modeling the kinds of workflows it sounds like you’re interested in. Branch protections are about preventing merges to specific branches, such as your repository’s default branch, so that the protected branch will always be clean and buildable, but people are free to push whatever they need to outside of the protected branches.
I hope that helps!