You would expect that if e.g. a GitHub webhook is delivered mentioning a particular branch/PR commit, then Jenkins upon processing this webhook would schedule one build of that commit.

      Instead, the commit identity from the webhook is essentially ignored, and the branch project is simply scheduled to be built, possibly coalescing with other near-simultaneous commits to the same branch depending on timing. When the build starts, the current branch head is looked up, to load Jenkinsfile typically, and only then will the commit be fixed for the remaining duration of the build.

      It would be better for MultiBranchProject.scheduleBuild to pass a SCMRevisionAction to the build from the start in the list of actions in the Queue.Item, if it happens to know the SCMRevision (whether from a webhook or branch indexing). Furthermore, SCMRevisionAction should implement Queue.QueueAction to ensure that queue items corresponding to distinct commits are not coalesced.

          [JENKINS-70408] Pass exact SCM revision from webhook

          Jesse Glick added a comment -

          In fact typical implementations of SCMHeadEvent.heads do track the commit hash. So far as I can tell this is used to avoid double builds in response to duplicated webhooks, but no more.

          Jesse Glick added a comment - In fact typical implementations of SCMHeadEvent.heads do track the commit hash. So far as I can tell this is used to avoid double builds in response to duplicated webhooks , but no more.

          jglick Hey there. I was wondering if you could elaborate more on what (if any) problematic behavior you see as a result of this issue?

          We're trying to track down an issue with automated SCM builds from GitHub webhooks intermittently not happening even though GitHub webhooks are being delivered successfully. Intermittent and hard to reproduce. Was curious if this issue could possibly be related.

          Elijah Shackelford added a comment - jglick Hey there. I was wondering if you could elaborate more on what (if any) problematic behavior you see as a result of this issue? We're trying to track down an issue with automated SCM builds from GitHub webhooks intermittently not happening even though GitHub webhooks are being delivered successfully. Intermittent and hard to reproduce. Was curious if this issue could possibly be related.

          Jesse Glick added a comment -

          eshack94 probably not related. The typical impact of this issue would be that you push two commits to the same branch to GH (in sequence, not in one push) and Jenkins winds up building only the later one.

          Jesse Glick added a comment - eshack94 probably not related. The typical impact of this issue would be that you push two commits to the same branch to GH (in sequence, not in one push) and Jenkins winds up building only the later one.

          rsandell added a comment -

          The reason it is also done like this is for security. Anyone could send the webhook trying to trick Jenkins into building something bad. So the payload in the webhook is only treated as a hint that there is probably an update in this repository on that specific branch/pr and schedules a scan of that particular thing to get the actual/trusted data.

          rsandell added a comment - The reason it is also done like this is for security. Anyone could send the webhook trying to trick Jenkins into building something bad. So the payload in the webhook is only treated as a hint that there is probably an update in this repository on that specific branch/pr and schedules a scan of that particular thing to get the actual/trusted data.

          Jesse Glick added a comment -

          That is why you would configure a webhook secret: the payload should be ignored only if it is unsigned (which would only even be sent to the github-branch-source listener if there were no secret configured, since otherwise git would reject it immediately).

          Jesse Glick added a comment - That is why you would configure a webhook secret: the payload should be ignored only if it is unsigned (which would only even be sent to the github-branch-source listener if there were no secret configured, since otherwise git would reject it immediately).

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: