[llvm-dev] GitHub Hooks

Daniel Berlin via llvm-dev
Wed, 20 Jul 2016 03:26:53 -0000

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 ...


On Tue, Jul 19, 2016 at 8:20 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:

> Not to derail a large portion of this thread by just pointing out how easy
> what you want to do is, but ...
>
> On Tue, Jul 19, 2016 at 1:27 PM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> So, there's been a bit of a misunderstanding about the hooks that
are
>> supported in GitHub, and after talking to the GitHub staff, I'd
like
>> to clarify what they are and how we can use them.
>>
>>
>>   1. Pre-commit hooks, avoiding forced pushes / re-order
>>
>> GitHub doesn't support server hooks due to security concerns.
>>
>> But there is an alternative:
>>
>> https://help.github.com/articles/about-required-status-checks/
>>
>> I don't know how we'd check for non-ff-merges with this, and
I'd
>> appreciate if someone with better GitHub knowledge could chime in. But
>> they *do* stop pushes from going in, which is what we want. Maybe we
>> would need a web-service (see 2) to get this working.
>>
>
> They do stop pushes, because you can require status checks.
>
> You don't need a web service. Anyone with push access can create a
status,
> or you can also
> grant oauth scope of repo:status to just grant status creation access
> without push access to code itself.
>
> 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.
> For example, Google's CLA bot uses
> https://github.com/google/go-github/tree/master/github to do it's work.
> There are libraries for every language you can think of, AFAIK (
> https://developer.github.com/libraries/)
>
> 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.
>
> In this case, what that means is "have thing" (cron job,
whatever), post
> state pending on every new request that comes in.
> As it figures out whether they are linear history or not, post state
> success/failed.
>
> 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).
>
> it will not allow push or merge until the required statuses are green.
>
>
> The interface also allows you to check "Require branches to be
up-to-date
> before merging".
>
> --Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/8cb738a0/attachment.html>