FYI, the kind of trick I would like to avoid to maintain is what this project is doing: https://github.com/deis/workflow-cli/blob/a285f6914f10ce81d0afe5d53603aa36cda78ccd/Jenkinsfile#L67
Le mercredi 5 juin 2019 16:03:34 UTC+2, Jesse Glick a écrit : > > On Wed, Jun 5, 2019 at 8:21 AM Julien HENRY > <[email protected] <javascript:>> wrote: > > Since the commit hash we are collecting currently in the pipeline is > something transient that doesn't exists on GitHub > > Note that as of JENKINS-43194 it _may_ be visible from GitHub APIs. I > would not advise relying on that, though. > > > Jenkins offers multiple PR strategies (with merge or not). So we would > have to do some logic to find if current commit is a merge commit > > Well my offhand suggestion was: > > · Try publishing a status for the recorded commit as is. If that worked, > great. > · If that gave a 422, and the commit was a merge commit, try > publishing a status for its parent parent. > > > some users are doing some Git operations in their pipeline. That could > affect our heuristic since our scanner may be called after they already > manipulated the repo. > > Yes, this is always a risk. > -- 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/792283f1-f5d7-4620-9d94-f7536b57d68b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
