This issue is just for documentation, since the issue went away with the update to gitlab-branch-source 1.4.4. Before that, a merge request would do a "fat" instead a lightweight checkout to read the Jenkinsfile and I cannot reproduce the issue when just a lightweight checkout is done.

      Pipeline sample code to have something to talk about:

      def repo = checkout scm
      echo repo.GIT_COMMIT
      

      This works correctly for branch builds, but not for merge request builds and the strategy "Merging the merge request with the current target branch revision" - when using that strategy, GIT_COMMIT points to a revision which doesn't exist after the merge, but instead to the merge commit from the "temporary" chechout which was done for reading the Jenkinsfile. Relevant log snippets:

      Branch indexing
      Querying the current revision of merge request #3...
      Current revision of merge request #3 is 367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      Checking out git https://<REPO>.git into /var/lib/jenkins/workspace/SOMETHING_MR-3@script to read Jenkinsfile
      [...]
       > git fetch --no-tags --force --progress -- https://<REPO>.git +refs/merge-requests/3/head:refs/remotes/origin/MR-3 +refs/heads/master:refs/remotes/origin/master # timeout=10
      Merging remotes/origin/master commit eb6a5804b1a07157304d00562a489437342049e1 into MR head commit 367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      [...]
      Merge succeeded, producing a9473d5a2d79ace679affe37853e74950602b07b
      Checking out Revision a9473d5a2d79ace679affe37853e74950602b07b (feature/update-slf4j)
      [...]
      Commit message: "Merge commit 'eb6a5804b1a07157304d00562a489437342049e1' into HEAD"
      [GitLab Pipeline Status] Notifying merge request build status: RUNNING tgruetzm/versions/ci/MR-3: Build started...
      [GitLab Pipeline Status] Notified
      Running in Durability level: PERFORMANCE_OPTIMIZED
      [...]
      [GitLab Pipeline Status] Notifying merge request build status: RUNNING tgruetzm/versions/ci/MR-3: Build started...
      [Pipeline] Start of Pipeline
      [...]
      [Pipeline] checkout
      [...]
      Merging remotes/origin/master commit eb6a5804b1a07157304d00562a489437342049e1 into MR head commit 367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      [...]
      Merge succeeded, producing bdabb0071fa91fe128c037a9f3352b459fcfcde8
      Checking out Revision bdabb0071fa91fe128c037a9f3352b459fcfcde8 (feature/update-slf4j)
      [...]
      Commit message: "Merge commit 'eb6a5804b1a07157304d00562a489437342049e1' into HEAD"
      First time build. Skipping changelog.
      [...]
      [Pipeline] echo
      {GIT_AUTHOR_EMAIL=xxx, GIT_AUTHOR_NAME=xxx, GIT_BRANCH=feature/update-slf4j, GIT_COMMIT=a9473d5a2d79ace679affe37853e74950602b07b, GIT_COMMITTER_EMAIL=xxx, GIT_COMMITTER_NAME=xxx, GIT_LOCAL_BRANCH=feature/update-slf4j, GIT_PREVIOUS_COMMIT=873ac16b7ac3b44ad9b45cdde7479a3dd73a4beb, GIT_PREVIOUS_SUCCESSFUL_COMMIT=367f5bc9835cecaf5929cf9a6a8d3600ad1dae32, GIT_URL=https://<REPO>.git}
      [...]
      + git log --oneline -2
      bdabb00 Merge commit 'eb6a5804b1a07157304d00562a489437342049e1' into HEAD
      eb6a580 Update test output
      [...]
      

      Now, with a lightweight checkout:

      Started by user Tobias Gruetzmacher
      Querying the current revision of merge request #3...
      Current revision of merge request #3 is 367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      Obtained Jenkinsfile from eb6a5804b1a07157304d00562a489437342049e1+367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      Running in Durability level: PERFORMANCE_OPTIMIZED
      [...]
      [GitLab Pipeline Status] Notifying merge request build status: RUNNING tgruetzm/versions/ci/MR-3: Build started...
      [GitLab Pipeline Status] Notified
      [Pipeline] Start of Pipeline
      [...]
      [Pipeline] checkout
      [...]
      Merging remotes/origin/master commit eb6a5804b1a07157304d00562a489437342049e1 into MR head commit 367f5bc9835cecaf5929cf9a6a8d3600ad1dae32
      [...]
      Merge succeeded, producing 793df539d53a54cb84316c39f81939c344255e4b
      Checking out Revision 793df539d53a54cb84316c39f81939c344255e4b (feature/update-slf4j)
      [...]
      Commit message: "Merge commit 'eb6a5804b1a07157304d00562a489437342049e1' into HEAD"
      First time build. Skipping changelog.
      [...]
      [Pipeline] echo
      {GIT_AUTHOR_EMAIL=xxx, GIT_AUTHOR_NAME=xxx, GIT_BRANCH=feature/update-slf4j, GIT_COMMIT=793df539d53a54cb84316c39f81939c344255e4b, GIT_COMMITTER_EMAIL=xxx, GIT_COMMITTER_NAME=xxx, GIT_LOCAL_BRANCH=feature/update-slf4j, GIT_PREVIOUS_COMMIT=a9473d5a2d79ace679affe37853e74950602b07b, GIT_PREVIOUS_SUCCESSFUL_COMMIT=367f5bc9835cecaf5929cf9a6a8d3600ad1dae32, GIT_URL=https://<REPO>.git}
      [...]
      + git log --oneline -2
      793df53 Merge commit 'eb6a5804b1a07157304d00562a489437342049e1' into HEAD
      eb6a580 Update test output
      [...]
      

          [JENKINS-61067] Wrong value for GIT_COMMIT after merge?

          We have the same issue with the PR.

          We are using Multibranch pipelines. If we peek ChangeRequestCheckoutStrategy.MERGE as a result it will try merge the existing branch and use  the SHA of it as GIT_COMMIT instead  of HEAD

           

           

          Oleksandr Tretiak added a comment - We have the same issue with the PR. We are using Multibranch pipelines. If we peek ChangeRequestCheckoutStrategy.MERGE as a result it will try merge the existing branch and use  the SHA of it as GIT_COMMIT instead  of HEAD    

          Workerround :

          String SHORT_COMMIT = sh (returnStdout: true, script: "git ls-remote -q  | awk '/${CHANGE_BRANCH.replace("/", "\\/")}/{print substr(\$0,0,7)}'").trim()
          

          Oleksandr Tretiak added a comment - Workerround : String SHORT_COMMIT = sh (returnStdout: true , script: "git ls-remote -q | awk '/${CHANGE_BRANCH.replace(" / ", " \\/ ")}/{print substr(\$0,0,7)}' " ).trim()

          Ing. Christoph Obexer added a comment - - edited

          GitLab offers the merged result as a ref that can be cloned, Jobs should be set up to reference that instead of using the Jenkinsfile from the branch tip and also instead of performing the merge during checkout scm.

          The GitLab documentation mentions the ref here: https://docs.gitlab.com/ee/api/merge_requests.html#merge-to-default-merge-ref-path

          If the ref is not available (because the merge has conflicts) the pipeline status should be set to failed and the Jenkins Job should turn red

          surenpi Can you take a look at this?

          Ing. Christoph Obexer added a comment - - edited GitLab offers the merged result as a ref that can be cloned, Jobs should be set up to reference that instead of using the Jenkinsfile from the branch tip and also instead of performing the merge during checkout scm. The GitLab documentation mentions the ref here: https://docs.gitlab.com/ee/api/merge_requests.html#merge-to-default-merge-ref-path If the ref is not available (because the merge has conflicts) the pipeline status should be set to failed and the Jenkins Job should turn red surenpi Can you take a look at this?

            Unassigned Unassigned
            tgr Tobias Gruetzmacher
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: