My scenario (as i would like it to be) is:
Is this scenario somehow possible or is it better to use a pre-receive hook?
Are webhooks serving as a kind of "information-service" after the event has happened and there is no way to prevent the event-action to happen if validations or anything else went wrong?
Would it be an idea to ammend the commit if the validations are NOT OK?
Solved! Solved! Go to Solution.
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:
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:
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!
Thank you very much for that detailed and helpfull answer.
I did not know that there is a standard way to do such things, but that way is working really well for me.
Thank you and have a great day!