Hi Brian, If you have any questions regarding plugins, it's better to use the jenkinsci-deb mailing list. I've added it to Cc and also included the current Git and Git Cilent plugin maintainers.
I suspect you refer a wrong plugin, because all merge and push operations are being performed by git-client plugin IIRC. The referenced class also comes from there. I suspect the plugin works as designed, because after the merge the Git client pushes two commits: 1 wirh the original SHA1 and another "merge" commit. Just check how many commits are being pushed. Best regards, Oleg 2015-09-11 1:24 GMT+03:00 Brian Colby <[email protected]>: > I spent some more time digging through the source, and I honestly can't > figure out where the command to get the SHA is coming from. I tracked it > down to a class called Request. > > Import hudson.plugins.git.Request > > But there is no such file in the git plugin repo. > > On Sep 10, 2015, at 11:16 AM, Brian Colby <[email protected]> wrote: > > Hi Oleg, > > I am tearing my hair out here trying to get the GitHub plugin to behave > the way I expect in a Jenkins build. The use case I am trying to do here > involves the advanced SCM step of merging the "triggering" commit to > master. Unfortunately, this action creates a new local SHA for the merge > commit which the plugin then uses when it tries to push a commit message > back to GItHub. Naturally this results in an error. > > I have tried overriding the env var GIT_COMMIT with the correct SHA, as > well as actually checking out the correct SHA in the workspace. Neither of > these tricks worked to convince the GitHub Plugin to push to the correct > SHA. > > So, I started poking through the source code for the plugin, which is > where I found your email. I am afraid I am starting blind here being very > inexperienced with java, as well as having no idea how these plugins get > written. > > I tracked down to this block, which I think is the method which is called > in the GitHubCommitNotifier.java which I believe performs the update to > GitHub. > > @Nonnull > > public static ObjectId getCommitSHA1(@Nonnull AbstractBuild<?, ?> > build) throws IOException { > > BuildData buildData = build.getAction(BuildData.class); > > if (buildData == null) { > > throw new > IOException(Messages.BuildDataHelper_NoBuildDataError()); > > } > > final Revision lastBuildRevision = > buildData.getLastBuiltRevision(); > > final ObjectId sha1 = lastBuildRevision != null ? > lastBuildRevision.getSha1() : null; > > if (sha1 == null) { // Nowhere to report => fail the build > > throw new > IOException(Messages.BuildDataHelper_NoLastRevisionError()); > > } > > return sha1; > > } > > > I am still trying to track this all the way down to where the "rubber > meets the road" and a SHA is actually determined. But if you could help > de-mystify this for me I would really appreciate it. > > > Cheers, > > > -Brian > > > p.s. Do you know if there is a way to access the payload from the POST > from GitHub that triggered the build at build time? I would like to use > some of that information for my build display name, but the actual payload > doesn't seem available to the triggered build. > > -- 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/CAPfivLDgoUY2NbU54bPiqHPeaoqNKM94ZyZKh1WoQoLnQB1hng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
