Re: GitHub Plugin updating a commit message after a merge.

[Oleg Nenashev]

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 <brian...@gmail.com>:

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 <brian...@gmail.com> 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.

[Mark Waite]

I'm not sure why you use the word "naturally" when you said:

> 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.

Can you explain further what the condition of the master branch is that would make it "natural" for the merge to fail?  

Does the triggering commit not merge cleanly to the master branch?  

Is the job configured to perform a merge?

I use multiple jobs which merge from a source branch to a destination.  I'm not clear what is different about your case compared to the cases which I use.

Mark Waite