<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Thomas De Schampheleire <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> schrieb am Mi., 19. Juli 2017 um 19:55 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2017-07-19 19:38 GMT+02:00 Long Vu <<a href="mailto:long.vu@intelerad.com" target="_blank">long.vu@intelerad.com</a>>:<br>
> On Wed, Jul 19, 2017 at 12:40 PM, Dominik Ruf <<a href="mailto:dominikruf@gmail.com" target="_blank">dominikruf@gmail.com</a>> wrote:<br>
>> Long Vu <<a href="mailto:long.vu@intelerad.com" target="_blank">long.vu@intelerad.com</a>> schrieb am Di., 18. Juli 2017 um 22:41 Uhr:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> If we want to fire some automated tests upon PR creation/update is<br>
>>> there some webhook for that?<br>
>>><br>
>>> I did not find any documentation about webhooks for Kallithea.  Just<br>
>>> wonder if there are really none or the documentation is simply lagging<br>
>>> behind.<br>
>>><br>
>>><br>
>>> I've found JSON-RPC API here<br>
>>> <a href="http://kallithea.readthedocs.io/en/latest/api/api.html" rel="noreferrer" target="_blank">http://kallithea.readthedocs.io/en/latest/api/api.html</a> but they do not<br>
>>> do what I need.<br>
>><br>
>> What is it that you are looking for?<br>
><br>
> Specifically some form of hooks/webhooks when a PR is created/updated.<br>
><br>
> The usecase is we want to fire Jenkins job with the content of the PR<br>
> to run automated test on it and report back to the PR that is has<br>
> passed or failed the test suite.<br>
><br>
> Basically more or less replicating the integration between AppVeyor<br>
> with Bitbucket for Kallithea itself.<br>
><br>
> We will also need some kind of JSON-RPC API to report back to the PR.<br>
><br>
> But for a start, a hook/webhook that fire upon PR creation/update is needed.<br>
<br>
I agree that such feature is useful.<br>
<br>
Regarding reporting back of such external validation steps towards<br>
kallithea PRs: this can be achieved in different ways, either a<br>
specific system, or by just treating such external validation as<br>
'reviewers' and let them add a comment and PR status via API.<br>
<br>
Same topic came up in the developer meeting early 2016. See subtopic<br>
'Workflow support' at<br>
<a href="https://bitbucket.org/conservancy/kallithea/wiki/DeveloperMeeting2016January" rel="noreferrer" target="_blank">https://bitbucket.org/conservancy/kallithea/wiki/DeveloperMeeting2016January</a><br>
<br>
Pasted here for convenience:<br>
<br>
-------<br>
Workflow support:<br>
- considering pull request/review request as 'a task' in a 'issue<br>
tracker'/'task tracker' could fix all these kinds of issues<br>
- Invite reviewers by group, for example an entire team, or module maintainers<br>
- Delegation of reviews by normal reviewers<br>
- Allow reviewers to review in differentiated capacities (e.g. review<br>
as maintainer of specific module)?<br>
- Split between required and optional reviewers<br>
- Unified reviewing and PR issue tracking? (would play well with all<br>
of the above)<br>
- "Automated reviewers" (style checks, CI test suites, etc.)<br>
- Avoid inviting real reviewers until the automated checks pass<br>
- How to better enable custom workflows (e.g. suggested/required reviewers)<br>
- Fitting Kallithea in a bigger delivery process (with compile-time<br>
validation, run-time validation, ...)<br>
- Unity: add local tag to show whether changes passed validation<br>
- Since requirements of organizations are different, just provide some<br>
proposed solution, or hook, or API, that an organization can hook into<br>
with their specific checks, or workflow steps.<br>
- Such checks could also be achieved by calling a web service when<br>
changes enter the system, letting an external system do all<br>
validation, then providing an API to give the results back to<br>
Kallithea (which then displays that in some form on the changeset or<br>
pullrequest).<br>
- Difference between notifications and 'tasks' (need action, have to<br>
mark as viewed, ...)<br>
----------<br>
<br>
I think we should decide upon some kind of roadmap after 1.0 and start<br>
discussing and implementing such features one by one.<br>
That is, I think we should try getting out 0.9 and 1.0 soon, with 0.9<br>
being current default + bootstrap, and 1.0 being 0.9 with some of the<br>
near-ready PRs finalized, and avoid diverting into new territory too<br>
much before 1.0 is out.<br></blockquote><div>I agree.</div><div>And I'd like to use this occasion to re-iterate on my suggestion to use JIRA</div><div>to manage the project.</div><div>I think JIRA could really help with planning releases.</div><div>It is also much easier, to discuss ideas, like the ones above, in JIRA, then in</div><div>a wiki, don't you think?</div><div><br></div><div>I'd also volontiere to manage JIRA.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
Thomas<br>
</blockquote></div></div>