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 [email protected]. 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.
