Any plans for the github checks API?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Any plans for the github checks API?

jxpearce

Someone on my team posted something about the new github checks API, which is like a better status API, providing detailed error info, etc.

Is anyone aware of if any plans to do anything with it in Jenkins? I wrote a plugin that watches jobs, and sends github status info (pending, succeeded, failed) github, and was considering extending it to support the new checks - but it also seems like something that might be better handled in a core plugin, so I was wondering whether there were any plans to add support.

Jeff

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d80e3d5a-b3fe-49a5-a081-18b0a2606c57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Any plans for the github checks API?

Jesse Glick-4
The `github-branch-source` plugin uses the older Status API. There might be some opportunities to improve the UX with the Checks API, I am not sure.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0o2gDsgDGeHbW3QfJ9OZS_G61uRnCVygEk6fc8r%2BsqpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Any plans for the github checks API?

Steven Foster
In reply to this post by jxpearce
The checks API looks great, but it seems like there is a disconnect between the all-in-one Pipeline of Jenkins and what the checks API expects to be working with. The examples in the article show elements such as linting, build, static analysis as separate and individually runnable things. In Jenkins 2.x Pipeline it feels like bundling these things together is more encouraged. While you can break things up a bit, it can become unwieldy when you get into things like multibranch building.

There's still a lot of potential for helpful usage of the API, these differences are just something that I find interesting when reading about software pipeline concepts and applications in abstract.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bb280e5a-d639-4029-8115-9379f10f37cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Any plans for the github checks API?

jxpearce
I'm not sure how the part about rerunning individual stages would work, but I could see rerunning the entire job from your github PR page. We sometimes have jobs where there are tests which fail occasionally, or 3rd party services are flakey, and in those cases just rerunning the job from github would save a step.

The part that might be interesting would be providing detailed information about why things failed on the PR page, with a list of actual errors. Granted this isn't easy, since there's not a consistent way to report errors, but the engineers I work with would *love* that level of integration. I would assume each "check" would be a single stage in the pipeline, so a routine job might have this set of checks:
  • checkout SCM
  • static checks
  • tests
  • deploy

On Thursday, May 10, 2018 at 2:37:39 AM UTC-7, Steven F wrote:
The checks API looks great, but it seems like there is a disconnect between the all-in-one Pipeline of Jenkins and what the checks API expects to be working with. The examples in the article show elements such as linting, build, static analysis as separate and individually runnable things. In Jenkins 2.x Pipeline it feels like bundling these things together is more encouraged. While you can break things up a bit, it can become unwieldy when you get into things like multibranch building.

There's still a lot of potential for helpful usage of the API, these differences are just something that I find interesting when reading about software pipeline concepts and applications in abstract.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1b15d973-093f-4e41-a7be-1bac3ff5e2e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Any plans for the github checks API?

Jesse Glick-4
In reply to this post by Steven Foster
On Thu, May 10, 2018 at 5:37 AM, Steven F <[hidden email]> wrote:
> The examples in the article show elements such as linting,
> build, static analysis as separate and individually runnable things. In
> Jenkins 2.x Pipeline it feels like bundling these things together is more
> encouraged.

Well, it is generally more straightforward to have those things be run
as part of a single Jenkins build, triggered by SCM changes. What is
missing is an API which would allow Jenkins report plugins (`Publisher
& SimpleBuildStep`, for example) to indicate to the system that there
is some information to be displayed in an abstract “change request”,
perhaps associated with source code lines, which would then be
implemented by `github-branch-source` with the Checks API.

[hidden email] wrote:
> just rerunning the job from github would save a step

See JENKINS-45455 for rerunning generally; again we would need a new
API to allow this is to be integrated with in-PR “chatops” triggers,
so that `github-branch-source` could receive GH events and refire them
as requests to rerun parts of a build, which
`pipeline-model-definition` would then interpret as a Declarative
build trigger.

All this would allow you to do more from GitHub and less from Blue
Ocean or the Jenkins “classic” UI. @abayer has done the most work in
this area and should probably be commenting.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0MNg5_9DFrFKnp%3Darrn06rkZTP-DzW%2BuwcVamF-TRSFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.