Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44562

getTrustedRevision for a non-merge untrusted PR build should be common ancestor with base branch

      As danielbeck noted, after PR 2890, some builds of PRs previously open failed, because they were loading Jenkinsfile from current master (where it expects a settings-azure.xml), but checking out scm from the PR head where this file does not exist. For example, PR-2903 #1 failed because the PR head commit was derived from a8994d4fa55eb4f5ba1b5a60837876c8107eeb95, long predating the merge of #2890. That should have been the PullRequestSCMRevision.baseHash. Instead it loaded from dd18af378f014e1aae706c0bb300bcb0f66342a9, after the merge, and thus not a common ancestor of the PR and the base branch. Did GitHub misreport the .base.sha, or is this field not in fact appropriate for the purpose? It is hard to tell in this example now, because the PR was already updated to merge with master.

          [JENKINS-44562] getTrustedRevision for a non-merge untrusted PR build should be common ancestor with base branch

          Daniel Beck added a comment -

          some builds of PRs previously open failed

          This case should be reproducible by just triggering any old PR again.

          In these two examples I mentioned in PR 2890, they were newer than the change to the Jenkinsfile, but based off a pre-merge commit. Just mentioning in case it's relevant.

          Daniel Beck added a comment - some builds of PRs previously open failed This case should be reproducible by just triggering any old PR again. In these two examples I mentioned in PR 2890, they were newer than the change to the Jenkinsfile, but based off a pre-merge commit. Just mentioning in case it's relevant.

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

              Created:
              Updated: