You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@yetus.apache.org by "Nick Dimiduk (Jira)" <ji...@apache.org> on 2020/03/05 16:00:06 UTC

[jira] [Commented] (YETUS-633) GitHub Checks integration

    [ https://issues.apache.org/jira/browse/YETUS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052286#comment-17052286 ] 

Nick Dimiduk commented on YETUS-633:
------------------------------------

bq. It is only available to Github Apps and can only be used via a callback. That means that the only place where checks might work that is on (AFAIK) anyone's roadmap would be as part of YETUS-578.

Is that still true? My read of the Checks API is that a GitHub _can_ initiate a call to the target application (ie, via a {{pull_request}} event). However, an application _could_ become aware of the presence of the change through some other means, for example, a polling job in Jenkins. Regardless of how the target application is notified, it's free to interact with the Check API, registering checks or suites and updating their progress. This is the scenario I am thinking through via YETUS-952, HBASE-23767.

Actions, Checks, Status... these are all so similar. Is there a document that summarizes which should be used by whom?

> GitHub Checks integration
> -------------------------
>
>                 Key: YETUS-633
>                 URL: https://issues.apache.org/jira/browse/YETUS-633
>             Project: Yetus
>          Issue Type: Wish
>          Components: Precommit
>            Reporter: Sean Busbey
>            Priority: Major
>
> GitHub has launched a feature for putting CI feedback into its own tab:
> https://github.com/apache/yetus/pull/12/checks
> Would be nice. lots of open questions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)