Bug: Autostatus does not work when pipeline is triggered by PR comment

[sgleske-ias]

Bug

Triggering builds with PR comments is provided by the pipeline-github-plugin.

When a build is triggered by the cause org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause then the GitHub autostatus plugin logs

INFO: Could not find commit sha - status will not be provided for this build

And does not vote status contexts to GitHub.

Additional information

However, after the build is completed (finished entirely) I can run the script console command to get the revision in a similar manner as this plugin.

More details (Click to expand)

---

Some investigation using the Jenkins script console.

import jenkins.model.Jenkins
import jenkins.scm.api.SCMRevisionAction
import org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision
import org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause

def build = Jenkins.instance.getItemByFullName('someproject/PR-1455').getBuild('2')

// the following returns org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause@14ba189
println build.getCause(IssueCommentCause)

// the following returns boolean true
println (build.getAction(SCMRevisionAction).getRevision() instanceof PullRequestSCMRevision)

// the following returns a proper SHA1 Git hash
println build.getAction(SCMRevisionAction).getRevision().getPullHash()

// the following returns class org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision
println build.getAction(SCMRevisionAction).getRevision().getClass()

Which the println statements return (in order)

• returns org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause@14ba189
• returns boolean true
• returns a proper SHA1 Git hash
• returns class org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision

---

Possible solution

It appears that build.getAction(SCMRevisionAction) is null when a build is first initiated but the first time an scm checkout occurs the run is populated with an SCMRevisionAction. This seems to be a unique situation when IssueCommentCause is the cause for triggering a build (so no SCM information is available, yet).

Does it make sense to add protective code where if GithubNotificationConfig.java gets a null result then to put in a "dummy" config which tries to update itself as revision information becomes available?

Reproduce Error

Setup environment

• Configure Jenkins to use webhooks with GitHub.
• Install pipeline-github plugin.
• Add a multibranch pipeline job for a project.
• Within a Jenkinsfile for a pull request have the following code:

// this will fail if merged into master but works from a pull request
properties([
    pipelineTriggers([
        issueCommentTrigger('.*test this please.*')
    ])
])
stage('hello') {
    echo 'hello'
}
stage('world') {
    echo 'world'
}

Reproduce issue

1. Let the PR pull request run at least once so that PR comment triggers get configured for the job.
2. Comment in the pull request retest this please.
3. After a "comment" build runs
   • it will update the GitHub status context continuous-integration/jenkins/pr-merge or continuous-integration/jenkins/pr-head depending on what you have configured in the multibranch job.
   • it will not update the status for stages. Notice the pr-merge (or pr-head) context will have the latest build but the stages will have the older build.

More info

I'm on github-autostatus plugin 3.2 so the relevant code from my Jenkins logging is https://github.com/jenkinsci/github-autostatus-plugin/blob/github-autostatus-3.2/src/main/java/org/jenkinsci/plugins/githubautostatus/GithubNotificationConfig.java#L148-L165

I looked at #29 which is the only update to that code in newer releases. I don't think upgrading will resolve my issue.

[sgleske-ias]

The same issue occurs when a user manually clicks the "build" button in a pull request job. So the SHA1 not being initially available is due to other causes like hudson.model.Cause$UserIdCause.

Manually triggered builds also have a lazy build.getAction(SCMRevisionAction).getRevision().getPullHash() which only becomes available upon first SCM checkout.

[sgleske-ias]

Seems like we have a pipeline step that causes the SCM to not be available in certain conditions. I think I'll be able to post reproducible steps for devs.

It happens under specific pipeline steps. When I have something reproducible I will comment here how to reproduce.

I think this is a github-autostatus bug because Jenkins logs show

Could not find commit sha - status will not be provided for this build

And then the pull requests never gets stages voted. I think it should retry to find the SCM and not give up on the whole pipeline. I'll figure out what the sequence of steps that are the exact root cause and post another update here.

[jeffpearce]

Let me know. There could be a bug in the plugin, but that log is informational level, so I don't know it's an indication. That seems more a symptom of the SCM being unavailable than the cause. But I'm happy to look at any repros

[jeffpearce]

Thanks for reminding me I need to look at this issue :-)

[samrocketman]

Just updating that I haven't had a chance to look further into this, yet. It's top of mind for me.

[sgleske-ias]

I'm still able to replicate this; I'm not sure of the exact cause still. However, when I run an SCM checkout at the beginning of the pipeline there are issues.