Github webhooks - pre-push hooks

Question

My requirement is that whenever developers are pushing to github, then before the push a CI build should trigger on Jenkins server. If that build fails, then push to github should be rejected. I need to write hooks for this, but I don't want to write client-side hooks as they can be disabled by developers. I want server-side github webhooks or pre-receive hooks.

Now, is this even possible to achieve ? If yes, then where to begin? Do I need knowledge of Rest API? Do I need to write shell scripts?

Answer 1

This isn't generally the workflow possible with GitHub.
You would rather use a "guarded commits" model with 2 GitHub repo:

• one for pushing, where you can enable a CI service like, for instance, Travis (or your own CI server),
• one for valid commits (the ones that passed CI), pushed by Travis (as in this question), and used by developer to sync their repo (pull only, no push)

---

that's what the requirement is for my project, which can't be changed

In that case, It is best to follow Building a CI server which will:

• detect the pushes and trigger a compilation
• push back on dedicated branch for valid comimt (it could be the master branch for instance)

That means the devs should push only to a "dev" branch, monitored by your server, and your CI engine would push those commits to the master branch if the compilation passes.

Answer 2

It's not possible to do exactly what you're asking for but it's possible to do something that should be close enough.

You can configure GitHub's hooks to invoke your CI server to run a build on every push. When the CI job is started, it should clone the repository and then forcibly push the branch to its previous state. If the build succeeds, push the branch again.

This requires your Jenkins job to have credentials that enable it to write to the repository.

However, you should understand that this method is prone to merge conflicts. It's possible that someone will push to the same branch while the first job is running (or worse, queued). You might have two jobs working on the same branch. Queued jobs are bound to cause problems, the least of which is that the branch will be updated on GitHub until the job runs and someone might pull the changes.

Having said this, my advice is that this workflow is not scalable. A possible alternative is to use protected branches and let your CI jobs merge feature branches into protected branches after successful builds (as long as it's a fast-forward merge).