PR webhooks to trigger automation?

Dominik Ruf dominikruf at gmail.com
Wed Jul 19 19:23:17 UTC 2017


Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Mi., 19.
Juli 2017 um 19:55 Uhr:

> 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.
>
I agree.
And I'd like to use this occasion to re-iterate on my suggestion to use JIRA
to manage the project.
I think JIRA could really help with planning releases.
It is also much easier, to discuss ideas, like the ones above, in JIRA,
then in
a wiki, don't you think?

I'd also volontiere to manage JIRA.


> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20170719/f3eeefea/attachment.html>


More information about the kallithea-general mailing list