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

Disable shallow clone when we know a merge will take place

      There is an issue when building pull requests and the clone trait is present with shallow clone option.
      Apparently you need some history in order to be able to do a merge.

      We need to disable shallow clone when we know a merge will take place.

      At the first look, this can be fixed in
      com.cloudbees.jenkins.plugins.bitbucket.BitbucketGitSCMBuilder
      org.jenkinsci.plugins.github_branch_source.GitHubSCMBuilder

      I had identified the problem using bitbucket-branch-source-plugin but the should be visible on github-branch-source-plugin also..

          [JENKINS-45771] Disable shallow clone when we know a merge will take place

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
          src/main/java/org/jenkinsci/plugins/gitclient/FetchCommand.java
          src/main/java/org/jenkinsci/plugins/gitclient/JGitAPIImpl.java
          http://jenkins-ci.org/commit/git-client-plugin/f445161be299b3cf0d54e893cfa7df39bb0058ee
          Log:
          JENKINS-45771 Missed one boolean builder

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java src/main/java/org/jenkinsci/plugins/gitclient/FetchCommand.java src/main/java/org/jenkinsci/plugins/gitclient/JGitAPIImpl.java http://jenkins-ci.org/commit/git-client-plugin/f445161be299b3cf0d54e893cfa7df39bb0058ee Log: JENKINS-45771 Missed one boolean builder

          Code changed in jenkins
          User: Mark Waite
          Path:
          pom.xml
          src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
          src/main/java/org/jenkinsci/plugins/gitclient/CloneCommand.java
          src/main/java/org/jenkinsci/plugins/gitclient/FetchCommand.java
          src/main/java/org/jenkinsci/plugins/gitclient/JGitAPIImpl.java
          src/main/java/org/jenkinsci/plugins/gitclient/PushCommand.java
          src/main/java/org/jenkinsci/plugins/gitclient/RevListCommand.java
          http://jenkins-ci.org/commit/git-client-plugin/d7ed207c99feecb5d0fc854e05ff0c3df2cd275e
          Log:
          Merge pull request #255 from stephenc/jenkins-45771

          JENKINS-45771 Ensure all command boolean options can be toggled, not just set once

          Compare: https://github.com/jenkinsci/git-client-plugin/compare/b0fa8071bdc1...d7ed207c99fe

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java src/main/java/org/jenkinsci/plugins/gitclient/CloneCommand.java src/main/java/org/jenkinsci/plugins/gitclient/FetchCommand.java src/main/java/org/jenkinsci/plugins/gitclient/JGitAPIImpl.java src/main/java/org/jenkinsci/plugins/gitclient/PushCommand.java src/main/java/org/jenkinsci/plugins/gitclient/RevListCommand.java http://jenkins-ci.org/commit/git-client-plugin/d7ed207c99feecb5d0fc854e05ff0c3df2cd275e Log: Merge pull request #255 from stephenc/jenkins-45771 JENKINS-45771 Ensure all command boolean options can be toggled, not just set once Compare: https://github.com/jenkinsci/git-client-plugin/compare/b0fa8071bdc1...d7ed207c99fe

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          pom.xml
          src/main/java/jenkins/plugins/git/MergeWithGitSCMExtension.java
          http://jenkins-ci.org/commit/git-plugin/b8c90a9461dc57633d97490d421a52796b0be2bb
          Log:
          [FIXED JENKINS-45771] Consolidate the MergeWithGitSCMExtension into git plugin

          With the update to git-client we can now fix the shallow clone issue on merge with

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: pom.xml src/main/java/jenkins/plugins/git/MergeWithGitSCMExtension.java http://jenkins-ci.org/commit/git-plugin/b8c90a9461dc57633d97490d421a52796b0be2bb Log: [FIXED JENKINS-45771] Consolidate the MergeWithGitSCMExtension into git plugin With the update to git-client we can now fix the shallow clone issue on merge with

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          pom.xml
          src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMBuilder.java
          src/main/java/org/jenkinsci/plugin/gitea/MergeWithGitSCMExtension.java
          http://jenkins-ci.org/commit/gitea-plugin/ed08e75e55f227e7d001dfd84a234fd477c7b831
          Log:
          JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: pom.xml src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMBuilder.java src/main/java/org/jenkinsci/plugin/gitea/MergeWithGitSCMExtension.java http://jenkins-ci.org/commit/gitea-plugin/ed08e75e55f227e7d001dfd84a234fd477c7b831 Log: JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          pom.xml
          src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilder.java
          src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
          src/main/java/org/jenkinsci/plugins/github_branch_source/MergeWithGitSCMExtension.java
          src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilderTest.java
          http://jenkins-ci.org/commit/github-branch-source-plugin/3256676fa6a47d342a0442c59555df9eecde0b68
          Log:
          JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: pom.xml src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilder.java src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java src/main/java/org/jenkinsci/plugins/github_branch_source/MergeWithGitSCMExtension.java src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMBuilderTest.java http://jenkins-ci.org/commit/github-branch-source-plugin/3256676fa6a47d342a0442c59555df9eecde0b68 Log: JENKINS-45771 Pick up consolidated MergeWithGitSCMExtension from git plugin

          Required plugin updates:

          • git-client 2.5.0
          • git 3.5.0
          • At least one of the optional plugin updates

          Optional plugin updates: (update any of these if already have installed, do not need to install a plugin if not installed already)

          • github-branch-source 2.2.3
          • gitea 1.0.1
          • bitbucket-branch-source 2.2.3

          Stephen Connolly added a comment - Required plugin updates: git-client 2.5.0 git 3.5.0 At least one of the optional plugin updates Optional plugin updates: (update any of these if already have installed, do not need to install a plugin if not installed already) github-branch-source 2.2.3 gitea 1.0.1 bitbucket-branch-source 2.2.3

          Shiqi Yang added a comment - - edited

          I found a case where this bug still applies in parallel stages, reopen this one since I think it is the same issue but please let me know if it is not and I can open another one

          environment:
          jenkins 2.89.3
          github-branch-source-plugin 2.32.2

          I have a multibranch project setup with
          `discover the pull requests from origin`
          `merge pull request with target`
          fetch all tags
          shallow clone

          I also have Basic Branch Build Strategies Plugin installed to stop the build storm when we scan repo but I don't think it is related

          my pipeline file has 2 parallel stages and one of the stages has its own node {} section to specify the builder label and workspace path.
          it looks like this (this is almost the same example of https://jenkins.io/blog/2017/09/25/declarative-1, only difference here is that I have customWorkspace specified on the nodes to reuse the local code repo in the hope to save some time on git clone, our git repo is huge):

          pipeline {
               agent none
              stages {
                  stage('Run Tests') {
                      parallel {
                          stage('Test 1') {
                              agent {
                                  label "windows"
                                  customWorkspace "${env.HOME}/TEST1"
                              }
                              steps {
                                  bat "run-tests.bat"
                              }
                              post {
                                  always {
                                      junit "**/TEST-*.xml"
                                  }
                              }
                          }
                          stage('Test On Linux') {
                              agent {
                                  label "linux"
                                  customWorkspace "${env.HOME}/TEST2"
                              }
                              steps {
                                  sh "run-tests.sh"
                              }
                              post {
                                  always {
                                      junit "**/TEST-*.xml"
                                  }
                              }
                          }
                      }
                  }
              }
          }
          

          the error I am seeing is that when the pipeline enters the parallel stages, especially after the workspace switch, it will fail to merge if the PR is couple of commits behind master because the head of master is checked out without git history. ( I logged in to the builder after the failure and manually verified that in the workspace)

          it seems that removing two ways to resolve this for now:
          1 remove the the customWorkspace this is not going to work well for us because the lack of self clean on the branches of multibranch (without customworkspace different branch runs will not share workspace in current design of multibranch pipeline)
          2. add 'wipe out workspace and clone again in advanced' settings. (this will increase our build time tremendously because our github repo is big, and unnecessary)

          > /usr/local/bin/git rev-parse --is-inside-work-tree # timeout=10
          
          Fetching changes from the remote Git repository
          
           > /usr/local/bin/git config remote.origin.url !INFO_EXTRACTED! # timeout=10
          
          Fetching upstream changes from !INFO_EXTRACTED!
          
           > /usr/local/bin/git --version # timeout=10
          
          using GIT_ASKPASS to set credentials JENKINS_GH
          
           > /usr/local/bin/git fetch --tags --progress !INFO_EXTRACTED! +refs/pull/!INFO_EXTRACTED!/head:refs/remotes/origin/PR-!INFO_EXTRACTED! +refs/heads/master:refs/remotes/origin/master # timeout=60
          
          Merging remotes/origin/master commit !INFO_EXTRACTED! into PR head commit !INFO_EXTRACTED!
          
           > /usr/local/bin/git config core.sparsecheckout # timeout=10
          
           > /usr/local/bin/git checkout -f !INFO_EXTRACTED!
          
           > /usr/local/bin/git merge !INFO_EXTRACTED! # timeout=10
          
           > /usr/local/bin/git config core.sparsecheckout # timeout=10
          
           > /usr/local/bin/git checkout -f !INFO_EXTRACTED!
          
          Command "/usr/local/bin/git merge !INFO_EXTRACTED!" returned status code 128:
          
          stdout: 
          
          stderr: fatal: refusing to merge unrelated histories
          

          FYI I remove the sensitive date from the output and replaced with ('!INFO_EXTRACTED')

          Shiqi Yang added a comment - - edited I found a case where this bug still applies in parallel stages, reopen this one since I think it is the same issue but please let me know if it is not and I can open another one environment: jenkins 2.89.3 github-branch-source-plugin 2.32.2 I have a multibranch project setup with `discover the pull requests from origin` `merge pull request with target` fetch all tags shallow clone I also have Basic Branch Build Strategies Plugin installed to stop the build storm when we scan repo but I don't think it is related my pipeline file has 2 parallel stages and one of the stages has its own node {} section to specify the builder label and workspace path. it looks like this (this is almost the same example of https://jenkins.io/blog/2017/09/25/declarative-1 , only difference here is that I have customWorkspace specified on the nodes to reuse the local code repo in the hope to save some time on git clone, our git repo is huge): pipeline { agent none stages { stage( 'Run Tests' ) { parallel { stage( 'Test 1' ) { agent { label "windows" customWorkspace "${env.HOME}/TEST1" } steps { bat "run-tests.bat" } post { always { junit "**/TEST-*.xml" } } } stage( 'Test On Linux' ) { agent { label "linux" customWorkspace "${env.HOME}/TEST2" } steps { sh "run-tests.sh" } post { always { junit "**/TEST-*.xml" } } } } } } } the error I am seeing is that when the pipeline enters the parallel stages, especially after the workspace switch, it will fail to merge if the PR is couple of commits behind master because the head of master is checked out without git history. ( I logged in to the builder after the failure and manually verified that in the workspace) it seems that removing two ways to resolve this for now: 1 remove the the customWorkspace this is not going to work well for us because the lack of self clean on the branches of multibranch (without customworkspace different branch runs will not share workspace in current design of multibranch pipeline) 2. add 'wipe out workspace and clone again in advanced' settings. (this will increase our build time tremendously because our github repo is big, and unnecessary) > /usr/local/bin/git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > /usr/local/bin/git config remote.origin.url !INFO_EXTRACTED! # timeout=10 Fetching upstream changes from !INFO_EXTRACTED! > /usr/local/bin/git --version # timeout=10 using GIT_ASKPASS to set credentials JENKINS_GH > /usr/local/bin/git fetch --tags --progress !INFO_EXTRACTED! +refs/pull/!INFO_EXTRACTED!/head:refs/remotes/origin/PR-!INFO_EXTRACTED! +refs/heads/master:refs/remotes/origin/master # timeout=60 Merging remotes/origin/master commit !INFO_EXTRACTED! into PR head commit !INFO_EXTRACTED! > /usr/local/bin/git config core.sparsecheckout # timeout=10 > /usr/local/bin/git checkout -f !INFO_EXTRACTED! > /usr/local/bin/git merge !INFO_EXTRACTED! # timeout=10 > /usr/local/bin/git config core.sparsecheckout # timeout=10 > /usr/local/bin/git checkout -f !INFO_EXTRACTED! Command "/usr/local/bin/git merge !INFO_EXTRACTED!" returned status code 128: stdout: stderr: fatal: refusing to merge unrelated histories FYI I remove the sensitive date from the output and replaced with ('!INFO_EXTRACTED')

          Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Nikolas Falco added a comment -

          I see all PR has been merged, could be this issue closed?

          Nikolas Falco added a comment - I see all PR has been merged, could be this issue closed?

          Mark Waite added a comment -

          I've done no investigation to see if the two repository use case described by shiqiyang is an issue. I don't plan to investigate that use case because I don't plan to take any action on that use case, even if it is an issue. I think that users who want to merge before release should use Pipeline and perform the merge from an sh step rather than relying on the git plugin to apply its custom logic for a merge. I don't plan to remove the feature from the git plugin, but I don't plan to invest significant effort to improve it either.

          Mark Waite added a comment - I've done no investigation to see if the two repository use case described by shiqiyang is an issue. I don't plan to investigate that use case because I don't plan to take any action on that use case, even if it is an issue. I think that users who want to merge before release should use Pipeline and perform the merge from an sh step rather than relying on the git plugin to apply its custom logic for a merge. I don't plan to remove the feature from the git plugin, but I don't plan to invest significant effort to improve it either.

            nfalco Nikolas Falco
            drealecs Alexandru Pătrănescu
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: