PR webhooks to trigger automation?

Thomas De Schampheleire patrickdepinguin at gmail.com
Wed Jul 19 17:54:44 UTC 2017


2017-07-19 19:38 GMT+02:00 Long Vu <long.vu at intelerad.com>:
> On Wed, Jul 19, 2017 at 12:40 PM, Dominik Ruf <dominikruf at gmail.com> wrote:
>> Long Vu <long.vu at intelerad.com> schrieb am Di., 18. Juli 2017 um 22:41 Uhr:
>>>
>>> Hi,
>>>
>>> If we want to fire some automated tests upon PR creation/update is
>>> there some webhook for that?
>>>
>>> I did not find any documentation about webhooks for Kallithea.  Just
>>> wonder if there are really none or the documentation is simply lagging
>>> behind.
>>>
>>>
>>> I've found JSON-RPC API here
>>> http://kallithea.readthedocs.io/en/latest/api/api.html but they do not
>>> do what I need.
>>
>> What is it that you are looking for?
>
> Specifically some form of hooks/webhooks when a PR is created/updated.
>
> The usecase is we want to fire Jenkins job with the content of the PR
> to run automated test on it and report back to the PR that is has
> passed or failed the test suite.
>
> Basically more or less replicating the integration between AppVeyor
> with Bitbucket for Kallithea itself.
>
> We will also need some kind of JSON-RPC API to report back to the PR.
>
> But for a start, a hook/webhook that fire upon PR creation/update is needed.

I agree that such feature is useful.

Regarding reporting back of such external validation steps towards
kallithea PRs: this can be achieved in different ways, either a
specific system, or by just treating such external validation as
'reviewers' and let them add a comment and PR status via API.

Same topic came up in the developer meeting early 2016. See subtopic
'Workflow support' at
https://bitbucket.org/conservancy/kallithea/wiki/DeveloperMeeting2016January

Pasted here for convenience:

-------
Workflow support:
- considering pull request/review request as 'a task' in a 'issue
tracker'/'task tracker' could fix all these kinds of issues
- Invite reviewers by group, for example an entire team, or module maintainers
- Delegation of reviews by normal reviewers
- Allow reviewers to review in differentiated capacities (e.g. review
as maintainer of specific module)?
- Split between required and optional reviewers
- Unified reviewing and PR issue tracking? (would play well with all
of the above)
- "Automated reviewers" (style checks, CI test suites, etc.)
- Avoid inviting real reviewers until the automated checks pass
- How to better enable custom workflows (e.g. suggested/required reviewers)
- Fitting Kallithea in a bigger delivery process (with compile-time
validation, run-time validation, ...)
- Unity: add local tag to show whether changes passed validation
- Since requirements of organizations are different, just provide some
proposed solution, or hook, or API, that an organization can hook into
with their specific checks, or workflow steps.
- Such checks could also be achieved by calling a web service when
changes enter the system, letting an external system do all
validation, then providing an API to give the results back to
Kallithea (which then displays that in some form on the changeset or
pullrequest).
- Difference between notifications and 'tasks' (need action, have to
mark as viewed, ...)
----------

I think we should decide upon some kind of roadmap after 1.0 and start
discussing and implementing such features one by one.
That is, I think we should try getting out 0.9 and 1.0 soon, with 0.9
being current default + bootstrap, and 1.0 being 0.9 with some of the
near-ready PRs finalized, and avoid diverting into new territory too
much before 1.0 is out.

Best regards,
Thomas


More information about the kallithea-general mailing list