Question

Does github provide

  • hooks to setup scripts to be run on every pull request (where say, one could call a simple static code analyser script)
  • and a provision to reject the pull request, based on the results from that script run via pull request hook.

Am trying to setup a pre-screener mechanism to catch trivial bugs/mistakes so that the reviewers are not bothered about trivial mistakes and they could focus more on the logic/feature. And if the prescreening script finds that the source in question doesn't fit the norms (typically, when even the simplest of checks fail; e.g, a function with >5000 SLoC, or unsafe strcpy(), or inclusion of deprecated header files etc), it should return a failure and pull request itself should fail unless the minimum gating criteria is met.

Since the code is on github rather than a local server, this seems to be kinda tricky.

I got a couple of pointers (here, and here) but still couldn't gather the details fully. The codebase consists of multiple repositories on github. Is there a better way to achieve and accomplish this? Please share your thoughts on possible approaches. Thanks!

Was it helpful?

Solution

Does GitHub provide hooks to setup scripts to be run on every pull request (where say, one could call a simple static code analyser script) and a provision to reject the pull request, based on the results from that script run via pull request hook.

This should be achievable through the GitHub Apis, by combining the creation of a hook for events of type pull_request, and then decorating the commits with a resulting status.

This is quite a low-level approach, but this lets you keep a complete control over what is being done. For instance, you could automatically add comments to the Pull Requests or even close them if they do not pass the analysis process.

Another higher level approach would be to leverage the Travis CI services through the addition of a .travis.yml file in your repository. Travis is free for opensource projects and also offers paid services for private repositories.

Setting up Travis is quite easy and tweaking the build script is a breeze.

Below two sample Travis scripts for your inspiration:

  • LibGit2: a C library. Build with several compilers, run tests, run Valgrind. The build fails (and the PR is decorated as such) when the code doesn't compile or upon a test failure.
  • LibGit2Sharp: A C# binding for LibGit2. Build against Mono Xbuild compiler, run tests. The build fails (and the PR is decorated as such) when the code doesn't compile or upon a test failure.

The official announcement for the GitHub Commit Status services can be read in this blog post.

OTHER TIPS

You may have use for this: https://github.com/tomasbjerre/violation-comments-to-github-lib

It will parse the file system to find report files from static code analyzers, and then use those to comment the pull request in GitHub.

enter image description here

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top