<div dir="ltr">Also note that github already blocks non-ff pushes unless you force (and you can't force a protected branch without being an admin, and you can even disable admins force-pushing), so ...<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 8:20 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Not to derail a large portion of this thread by just pointing out how easy what you want to do is, but ...</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Jul 19, 2016 at 1:27 PM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, there's been a bit of a misunderstanding about the hooks that are<br>
supported in GitHub, and after talking to the GitHub staff, I'd like<br>
to clarify what they are and how we can use them.<br>
<br>
<br>
  1. Pre-commit hooks, avoiding forced pushes / re-order<br>
<br>
GitHub doesn't support server hooks due to security concerns.<br>
<br>
But there is an alternative:<br>
<br>
<a href="https://help.github.com/articles/about-required-status-checks/" rel="noreferrer" target="_blank">https://help.github.com/articles/about-required-status-checks/</a><br>
<br>
I don't know how we'd check for non-ff-merges with this, and I'd<br>
appreciate if someone with better GitHub knowledge could chime in. But<br>
they *do* stop pushes from going in, which is what we want. Maybe we<br>
would need a web-service (see 2) to get this working.<br></blockquote><div><br></div></span><div>They do stop pushes, because you can require status checks.</div><div><br></div><div>You don't need a web service. Anyone with push access can create a status, or you can also</div><div>grant oauth scope of repo:status to just grant status creation access without push access to code itself.</div><div><br></div><div>All you have to do to create a status is post to a specific URL (and include your access tokens, blah blah blah).  You can use the context field to say what service created the status, etc.   There are libraries for all of it.</div><div>For example, Google's CLA bot uses <a href="https://github.com/google/go-github/tree/master/github" target="_blank">https://github.com/google/go-github/tree/master/github</a> to do it's work.</div><div>There are libraries for every language you can think of, AFAIK (<a href="https://developer.github.com/libraries/" target="_blank">https://developer.github.com/libraries/</a>)</div><div><br></div><div>In any case, all you would have to is post a status of state failed to the ref for the pull request, and it will reflect in the pull request.</div><div><br></div><div>In this case, what that means is "have thing" (cron job, whatever), post state pending on every new request that comes in.</div><div>As it figures out whether they are linear history or not, post state success/failed.</div><div><br></div><div>You can then mark whatever status checks you want as required for a given branch (it'll give you a dropdown of status types it finds in the past week).</div><div><br></div><div>it will not allow push or merge until the required statuses are green.</div><div><br></div><div><br></div><div>The interface also allows you to check "Require branches to be up-to-date before merging".</div><div><br></div><div>--Dan</div><div><br></div></div></div></div>
</blockquote></div><br></div>