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

BitBucket PRs failing to checkout on initial run after PR updated with new commits

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Updating an existing Pull-Request with additional commits leads to broken builds of the Pull Request, because jenkins tries to check out a not existing ref in git.

      Reproduction:

      • create a branch in the repository
      • create a new commit 
      • create a multibranch job building all branches and pull requests
      • create a new pull request in Bitbucket server from the new branch to master
      • scan for changes in the multibranch job -> the first build of the PR succeeds
      • change some files on the branch and commit with the --amend flag set and push with force flag Edit: Found out, that a normal commit to the branch also crashes the build.
      • scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
      • After visiting the Pull-Request overview in Bitbucket, following builds succeed

       

      This is the jenkins console output:

      Started by user admin
      Checking out git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git into /var/jenkins_home/workspace/failing-builds_PR-3-5GPUDFBBY64BPS5T63E3TRH74RJSNKWF5A6YELFFKHSOT5HTAQ4A@script to read Jenkinsfile
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from 2 remote Git repositories
       > git config remote.origin.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
      Fetching without tags
      Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
       > git --version # timeout=10
      using GIT_ASKPASS to set credentials Bitbucket-Server Account
       > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/pull-requests/3/from:refs/remotes/origin/PR-3
       > git config remote.upstream.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
      Fetching without tags
      Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
      using GIT_ASKPASS to set credentials Bitbucket-Server Account
       > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/heads/master:refs/remotes/upstream/master
      Merging remotes/upstream/master commit d4eaaccd2e0f61e87b2a48fcae8a8b6693038a48 into PR head commit cec48748dc421b835274476029a9c98123babc15
       > git config core.sparsecheckout # timeout=10
       > git checkout -f cec48748dc421b835274476029a9c98123babc15
      [Bitbucket] Notifying pull request build result
      [Bitbucket] Build result notified
      hudson.plugins.git.GitException: Command "git checkout -f cec48748dc421b835274476029a9c98123babc15" returned status code 128:
      stdout: 
      stderr: fatal: reference is not a tree: cec48748dc421b835274476029a9c98123babc15
      
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:71)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2214)
      Caused: hudson.plugins.git.GitException: Could not checkout cec48748dc421b835274476029a9c98123babc15
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2237)
      	at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
      	at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
      	at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1023)
      	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1116)
      	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
      	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
      	at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:246)
      	at hudson.model.ResourceController.execute(ResourceController.java:97)
      	at hudson.model.Executor.run(Executor.java:405)
      Finished: FAILURE

      I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.

      This is the full answer from atlassian:

      I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
      When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.

        Attachments

          Issue Links

            Activity

            mkaulig Michael Kaulig created issue -
            mkaulig Michael Kaulig made changes -
            Field Original Value New Value
            Description In our workflow we often use "commit --amend && push -f" to update a pull request after someone commented the code. After the push the scan for the job sees, that the pull request was updated and tries to build it. The resulting build of the pull request fails, because it points to a not existing ref in git.

            Reproduction:
             * create a branch in the repository
             * create a new commit 
             * create a multibranch job building all branches and pull requests
             * create a new pull request in Bitbucket server from the new branch to master
             * scan for changes in the multibranch job -> the first build of the PR succeeds
             * change some files on the branch and commit with the --amend flag set and push with force flag
             * scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
             * After visiting the Pull-Request overview in Bitbucket, following builds succeed

             

            This is the jenkins console output:
            {code:java}
            Started by user admin
            Checking out git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git into /var/jenkins_home/workspace/failing-builds_PR-3-5GPUDFBBY64BPS5T63E3TRH74RJSNKWF5A6YELFFKHSOT5HTAQ4A@script to read Jenkinsfile
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from 2 remote Git repositories
             > git config remote.origin.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
             > git --version # timeout=10
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/pull-requests/3/from:refs/remotes/origin/PR-3
             > git config remote.upstream.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/heads/master:refs/remotes/upstream/master
            Merging remotes/upstream/master commit d4eaaccd2e0f61e87b2a48fcae8a8b6693038a48 into PR head commit cec48748dc421b835274476029a9c98123babc15
             > git config core.sparsecheckout # timeout=10
             > git checkout -f cec48748dc421b835274476029a9c98123babc15
            [Bitbucket] Notifying pull request build result
            [Bitbucket] Build result notified
            hudson.plugins.git.GitException: Command "git checkout -f cec48748dc421b835274476029a9c98123babc15" returned status code 128:
            stdout:
            stderr: fatal: reference is not a tree: cec48748dc421b835274476029a9c98123babc15

            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:71)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2214)
            Caused: hudson.plugins.git.GitException: Could not checkout cec48748dc421b835274476029a9c98123babc15
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2237)
            at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
            at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
            at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1023)
            at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1116)
            at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
            at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
            at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
            at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:246)
            at hudson.model.ResourceController.execute(ResourceController.java:97)
            at hudson.model.Executor.run(Executor.java:405)
            Finished: FAILURE{code}
            I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.

            This is the full answer from atlassian:

            {quote}
            I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
             When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.
            {quote}
            In our workflow we often use "commit --amend && push -f" to update a pull request after someone commented the code. After the push the scan for the job sees, that the pull request was updated and tries to build it. The resulting build of the pull request fails, because it points to a not existing ref in git.

            Reproduction:
             * create a branch in the repository
             * create a new commit 
             * create a multibranch job building all branches and pull requests
             * create a new pull request in Bitbucket server from the new branch to master
             * scan for changes in the multibranch job -> the first build of the PR succeeds
             * change some files on the branch and commit -with the --amend flag set- and push -with force flag- Edit: Found out, that a normal commit to the branch also crashes the build.
             * scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
             * After visiting the Pull-Request overview in Bitbucket, following builds succeed

             

            This is the jenkins console output:
            {code:java}
            Started by user admin
            Checking out git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git into /var/jenkins_home/workspace/failing-builds_PR-3-5GPUDFBBY64BPS5T63E3TRH74RJSNKWF5A6YELFFKHSOT5HTAQ4A@script to read Jenkinsfile
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from 2 remote Git repositories
             > git config remote.origin.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
             > git --version # timeout=10
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/pull-requests/3/from:refs/remotes/origin/PR-3
             > git config remote.upstream.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/heads/master:refs/remotes/upstream/master
            Merging remotes/upstream/master commit d4eaaccd2e0f61e87b2a48fcae8a8b6693038a48 into PR head commit cec48748dc421b835274476029a9c98123babc15
             > git config core.sparsecheckout # timeout=10
             > git checkout -f cec48748dc421b835274476029a9c98123babc15
            [Bitbucket] Notifying pull request build result
            [Bitbucket] Build result notified
            hudson.plugins.git.GitException: Command "git checkout -f cec48748dc421b835274476029a9c98123babc15" returned status code 128:
            stdout:
            stderr: fatal: reference is not a tree: cec48748dc421b835274476029a9c98123babc15

            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:71)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2214)
            Caused: hudson.plugins.git.GitException: Could not checkout cec48748dc421b835274476029a9c98123babc15
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2237)
            at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
            at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
            at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1023)
            at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1116)
            at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
            at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
            at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
            at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:246)
            at hudson.model.ResourceController.execute(ResourceController.java:97)
            at hudson.model.Executor.run(Executor.java:405)
            Finished: FAILURE{code}
            I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.

            This is the full answer from atlassian:
            {quote}I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
             When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.
            {quote}
            mkaulig Michael Kaulig made changes -
            Summary PRs failing after force push PRs failing after update
            mkaulig Michael Kaulig made changes -
            Summary PRs failing after update PRs failing on update
            mkaulig Michael Kaulig made changes -
            Description In our workflow we often use "commit --amend && push -f" to update a pull request after someone commented the code. After the push the scan for the job sees, that the pull request was updated and tries to build it. The resulting build of the pull request fails, because it points to a not existing ref in git.

            Reproduction:
             * create a branch in the repository
             * create a new commit 
             * create a multibranch job building all branches and pull requests
             * create a new pull request in Bitbucket server from the new branch to master
             * scan for changes in the multibranch job -> the first build of the PR succeeds
             * change some files on the branch and commit -with the --amend flag set- and push -with force flag- Edit: Found out, that a normal commit to the branch also crashes the build.
             * scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
             * After visiting the Pull-Request overview in Bitbucket, following builds succeed

             

            This is the jenkins console output:
            {code:java}
            Started by user admin
            Checking out git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git into /var/jenkins_home/workspace/failing-builds_PR-3-5GPUDFBBY64BPS5T63E3TRH74RJSNKWF5A6YELFFKHSOT5HTAQ4A@script to read Jenkinsfile
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from 2 remote Git repositories
             > git config remote.origin.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
             > git --version # timeout=10
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/pull-requests/3/from:refs/remotes/origin/PR-3
             > git config remote.upstream.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/heads/master:refs/remotes/upstream/master
            Merging remotes/upstream/master commit d4eaaccd2e0f61e87b2a48fcae8a8b6693038a48 into PR head commit cec48748dc421b835274476029a9c98123babc15
             > git config core.sparsecheckout # timeout=10
             > git checkout -f cec48748dc421b835274476029a9c98123babc15
            [Bitbucket] Notifying pull request build result
            [Bitbucket] Build result notified
            hudson.plugins.git.GitException: Command "git checkout -f cec48748dc421b835274476029a9c98123babc15" returned status code 128:
            stdout:
            stderr: fatal: reference is not a tree: cec48748dc421b835274476029a9c98123babc15

            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:71)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2214)
            Caused: hudson.plugins.git.GitException: Could not checkout cec48748dc421b835274476029a9c98123babc15
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2237)
            at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
            at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
            at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1023)
            at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1116)
            at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
            at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
            at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
            at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:246)
            at hudson.model.ResourceController.execute(ResourceController.java:97)
            at hudson.model.Executor.run(Executor.java:405)
            Finished: FAILURE{code}
            I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.

            This is the full answer from atlassian:
            {quote}I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
             When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.
            {quote}
            Updating an existing Pull-Request with additional commits leads to broken builds of the Pull Request, because jenkins tries to check out a not existing ref in git.

            Reproduction:
             * create a branch in the repository
             * create a new commit 
             * create a multibranch job building all branches and pull requests
             * create a new pull request in Bitbucket server from the new branch to master
             * scan for changes in the multibranch job -> the first build of the PR succeeds
             * change some files on the branch and commit -with the --amend flag set- and push -with force flag- Edit: Found out, that a normal commit to the branch also crashes the build.
             * scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
             * After visiting the Pull-Request overview in Bitbucket, following builds succeed

             

            This is the jenkins console output:
            {code:java}
            Started by user admin
            Checking out git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git into /var/jenkins_home/workspace/failing-builds_PR-3-5GPUDFBBY64BPS5T63E3TRH74RJSNKWF5A6YELFFKHSOT5HTAQ4A@script to read Jenkinsfile
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from 2 remote Git repositories
             > git config remote.origin.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
             > git --version # timeout=10
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/pull-requests/3/from:refs/remotes/origin/PR-3
             > git config remote.upstream.url http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git # timeout=10
            Fetching without tags
            Fetching upstream changes from http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git
            using GIT_ASKPASS to set credentials Bitbucket-Server Account
             > git fetch --no-tags --progress http://xstash.itd.meisterplan.io/scm/mp/failing-builds.git +refs/heads/master:refs/remotes/upstream/master
            Merging remotes/upstream/master commit d4eaaccd2e0f61e87b2a48fcae8a8b6693038a48 into PR head commit cec48748dc421b835274476029a9c98123babc15
             > git config core.sparsecheckout # timeout=10
             > git checkout -f cec48748dc421b835274476029a9c98123babc15
            [Bitbucket] Notifying pull request build result
            [Bitbucket] Build result notified
            hudson.plugins.git.GitException: Command "git checkout -f cec48748dc421b835274476029a9c98123babc15" returned status code 128:
            stdout:
            stderr: fatal: reference is not a tree: cec48748dc421b835274476029a9c98123babc15

            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:71)
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2214)
            Caused: hudson.plugins.git.GitException: Could not checkout cec48748dc421b835274476029a9c98123babc15
            at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2237)
            at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
            at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
            at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1023)
            at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1116)
            at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
            at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
            at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
            at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:246)
            at hudson.model.ResourceController.execute(ResourceController.java:97)
            at hudson.model.Executor.run(Executor.java:405)
            Finished: FAILURE{code}
            I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.

            This is the full answer from atlassian:
            {quote}I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
             When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.
            {quote}
            mkaulig Michael Kaulig made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            Hide
            adaphi Philip Adams added a comment -

            We are also seeing this issue. It renders Jenkins basically unusable for PR jobs, as someone has to visit the PR page between every commit.

            Show
            adaphi Philip Adams added a comment - We are also seeing this issue. It renders Jenkins basically unusable for PR jobs, as someone has to visit the PR page between every commit .
            Hide
            mmuth Matthias Muth added a comment -

            Same here. This is a huge problem for our CI pipeline

            Show
            mmuth Matthias Muth added a comment - Same here. This is a huge problem for our CI pipeline
            Hide
            jay_hendren jay hendren added a comment -

            Here is the corresponding bug report on the Bitbucket JIRA:

            https://jira.atlassian.com/browse/BSERV-5288

            Show
            jay_hendren jay hendren added a comment - Here is the corresponding bug report on the Bitbucket JIRA: https://jira.atlassian.com/browse/BSERV-5288
            Hide
            jay_hendren jay hendren added a comment - - edited

            And here is a much more detailed response from the Atlassian developer who created this "feature":

            https://community.atlassian.com/t5/Bitbucket-questions/Change-pull-request-refs-after-Commit-instead-of-after-Approval/qaq-p/194702#M6829

            I believe this explanation gives rise to a potential workaround. Specifically, the developer mentions that hitting the canMerge() API endpoint triggers an update of the refs. The plugin that I'm using to trigger Jenkins when PRs are updated (I believe it's called "pull-request-notifier" or something like that) supports checking whether the PR has any merge conflicts. I'm guessing the plugin uses the canMerge() endpoint to do so, which should hopefully triggers a ref update. I'm going to do some testing and report back.

            Show
            jay_hendren jay hendren added a comment - - edited And here is a much more detailed response from the Atlassian developer who created this "feature": https://community.atlassian.com/t5/Bitbucket-questions/Change-pull-request-refs-after-Commit-instead-of-after-Approval/qaq-p/194702#M6829 I believe this explanation gives rise to a potential workaround. Specifically, the developer mentions that hitting the canMerge() API endpoint triggers an update of the refs. The plugin that I'm using to trigger Jenkins when PRs are updated (I believe it's called "pull-request-notifier" or something like that) supports checking whether the PR has any merge conflicts. I'm guessing the plugin uses the canMerge() endpoint to do so, which should hopefully triggers a ref update. I'm going to do some testing and report back.
            Hide
            jay_hendren jay hendren added a comment - - edited

            Okay, I am pleased to report that my workaround appears to be working. Here is what I did:

            I'm using the pull-request-notifier-for-bitbucket plugin to trigger Jenkins builds from Bitbucket whenever a PR is created/updated. This plugin has an option to only trigger builds if the PR has no merge conflicts. I had this setting in the "always" state, meaning the plugin would trigger a build without checking to see if there were any merge conflicts. I changed this setting to only trigger a build if there are no merge conflicts, and the reference is not a tree errors have gone away and builds are running successfully now when PRs are updated.

            The specific value I changed in the plugin settings is:

            "triggerIfCanMerge":"ALWAYS"
            

            to:

            "triggerIfCanMerge":"NOT_CONFLICTING"
            
            Show
            jay_hendren jay hendren added a comment - - edited Okay, I am pleased to report that my workaround appears to be working. Here is what I did: I'm using the pull-request-notifier-for-bitbucket plugin to trigger Jenkins builds from Bitbucket whenever a PR is created/updated. This plugin has an option to only trigger builds if the PR has no merge conflicts. I had this setting in the "always" state, meaning the plugin would trigger a build without checking to see if there were any merge conflicts. I changed this setting to only trigger a build if there are no merge conflicts, and the reference is not a tree errors have gone away and builds are running successfully now when PRs are updated. The specific value I changed in the plugin settings is: "triggerIfCanMerge" : "ALWAYS" to: "triggerIfCanMerge" : "NOT_CONFLICTING"
            jay_hendren jay hendren made changes -
            Link This issue is duplicated by JENKINS-46183 [ JENKINS-46183 ]
            jay_hendren jay hendren made changes -
            Link This issue is duplicated by JENKINS-45891 [ JENKINS-45891 ]
            abayer Andrew Bayer made changes -
            Link This issue relates to JENKINS-46174 [ JENKINS-46174 ]
            abayer Andrew Bayer made changes -
            Link This issue relates to JENKINS-45973 [ JENKINS-45973 ]
            abayer Andrew Bayer made changes -
            Summary PRs failing on update BitBucket PRs failing to checkout on update
            abayer Andrew Bayer made changes -
            Summary BitBucket PRs failing to checkout on update BitBucket PRs failing to checkout on initial run after PR updated with new commits
            Hide
            pixman20 pixman20 added a comment -

            Thanks for the workaround jay hendren !!!
            Just to assist anyone else using this plugin as a workaround as well:

            Steps to create the notification via the UI:

            • Go to the repository (or project) settings
            • Scroll down to Notifications
            • Add a name
            • Select "trigger only when merge is not conflicting"
            • Select "RESCOPED_FROM, new commits on source branch."
            • For the URL, you can put: "http://localhost/nowhere" or whatever if you aren't relying on this PR's notifications (i.e. only the Bitbucket Branch Source Plugin) since the canMerge() API is called before invoking the URL, which at that point no longer matters.
            Show
            pixman20 pixman20 added a comment - Thanks for the workaround jay hendren !!! Just to assist anyone else using this plugin as a workaround as well: Steps to create the notification via the UI: Go to the repository (or project) settings Scroll down to Notifications Add a name Select "trigger only when merge is not conflicting" Select "RESCOPED_FROM, new commits on source branch." For the URL, you can put: "http://localhost/nowhere" or whatever if you aren't relying on this PR's notifications (i.e. only the Bitbucket Branch Source Plugin) since the canMerge() API is called before invoking the URL, which at that point no longer matters.
            Hide
            netappbluedevil NetAppBlueDevil added a comment -

            Any known workaround when using Bitbucket Branch Source Plugin?  I'm seeing this same issue there.

            Show
            netappbluedevil NetAppBlueDevil added a comment - Any known workaround when using Bitbucket Branch Source Plugin?  I'm seeing this same issue there.
            Hide
            kit Kit Plummer added a comment -

            Definitely interested in a fix for the Bitbucket plugin as well.  Sometimes 'rescanning' the branches allows it to work, most times not.

            Show
            kit Kit Plummer added a comment - Definitely interested in a fix for the Bitbucket plugin as well.  Sometimes 'rescanning' the branches allows it to work, most times not.
            Hide
            jay_hendren jay hendren added a comment - - edited

            NetAppBlueDevil, kitplummer - I think there may be some confusion here. This bug report is already a bug report for the Bitbucket Branch Source Plugin for Jenkins. All of us who have commented here are using that plugin. I reported a workaround that could be used if you also happen to be using the pull-request-notifier plugin for Bitbucket. pixman20 then reported that this workaround can also be used if you are not currently using the pull-request-notifier plugin - basically, you can install this plugin on your Bitbucket instance, then configure it to run a noop request and also configure it for the workaround I posted.

            Show
            jay_hendren jay hendren added a comment - - edited NetAppBlueDevil , kitplummer - I think there may be some confusion here. This bug report is already a bug report for the Bitbucket Branch Source Plugin for Jenkins. All of us who have commented here are using that plugin. I reported a workaround that could be used if you also happen to be using the pull-request-notifier plugin for Bitbucket. pixman20 then reported that this workaround can also be used if you are not currently using the pull-request-notifier plugin - basically, you can install this plugin on your Bitbucket instance, then configure it to run a noop request and also configure it for the workaround I posted.
            Hide
            justinwojo Justin Wojciechowski added a comment -

            If the Bitbucket Branch Source Plugin added a setting to poll the CanMerge before build it would be a simple fix/workaround for it. This is a huge annoyance for my team using Jenkins. Constantly have PR's failing and have to go view the PR in Bitbucket and re-kick off the build on new commits. Very frustrating. 

            Also, The workaround that pixman20 mentioned requires installing the "Pull Request Notifier for BitBucket" plugin on BitBucket's end. Unfortunately our Bitbucket Server is too old to install it, but we're upgrading it shortly. I'll test the workaround with that plugin and verify it works around this issue.

             

            I was able to "fix" the issue by calling the Bitbucket API to verify the merge before building. The issue though is with the MutliBranch pipeline, it gets the Jenkinsfile, and performs the merge which breaks. I added this logic to the Jenkinsfile itself, which doesn't get called before the "reference is not tree" error occurs. Very frustrating.

            Show
            justinwojo Justin Wojciechowski added a comment - If the Bitbucket Branch Source Plugin added a setting to poll the CanMerge before build it would be a simple fix/workaround for it. This is a huge annoyance for my team using Jenkins. Constantly have PR's failing and have to go view the PR in Bitbucket and re-kick off the build on new commits. Very frustrating.  Also, The workaround that pixman20 mentioned requires installing the "Pull Request Notifier for BitBucket" plugin on BitBucket's end. Unfortunately our Bitbucket Server is too old to install it, but we're upgrading it shortly. I'll test the workaround with that plugin and verify it works around this issue.   I was able to "fix" the issue by calling the Bitbucket API to verify the merge before building. The issue though is with the MutliBranch pipeline, it gets the Jenkinsfile, and performs the merge which breaks. I added this logic to the Jenkinsfile itself, which doesn't get called before the "reference is not tree" error occurs. Very frustrating.
            roolebo Roman Bolshakov made changes -
            Link This issue relates to JENKINS-48737 [ JENKINS-48737 ]
            Hide
            nickbrown Nicholas Brown added a comment -

            I think Justin Wojciechowski solution of having the Bitbucket Branch Source Plugin hit the CanMerge Rest API, to force the branch creations, is a good one. It need not even be a configuration option, Bitbucket Branch Source Plugin should simply do this every time it discovers PRs.

            In a some older Jenkins jobs I had, not making use of Bitbucket Branch Source Plugin, I had the same issue and used this horrid work around:

            # Nasty hack to force Stash to generate the /merge branch for the PR
            set +x
            curl -u ${STASH_USER}:${STASH_PASSWORD} ${STASH_URL}/rest/api/1.0/projects/${destinationRepositoryOwner}/repos/${destinationRepositoryName}/pull-requests/${pullRequestId}/diff > /dev/null
            
            Show
            nickbrown Nicholas Brown added a comment - I think Justin Wojciechowski solution of having the Bitbucket Branch Source Plugin hit the CanMerge Rest API, to force the branch creations, is a good one. It need not even be a configuration option, Bitbucket Branch Source Plugin should simply do this every time it discovers PRs. In a some older Jenkins jobs I had, not making use of Bitbucket Branch Source Plugin, I had the same issue and used this horrid work around: # Nasty hack to force Stash to generate the /merge branch for the PR set +x curl -u ${STASH_USER}:${STASH_PASSWORD} ${STASH_URL}/rest/api/1.0/projects/${destinationRepositoryOwner}/repos/${destinationRepositoryName}/pull-requests/${pullRequestId}/diff > /dev/null
            Show
            tario Patrick Ruckstuhl added a comment - Created https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/116 with exactly this
            thokuest Thomas Küstermann made changes -
            Remote Link This issue links to "Pull Request #116 (Web Link)" [ 20327 ]
            Hide
            soar Aleksey Smyrnov added a comment -

            I've faced same problem today - but with GitHub and it's Pull Requests:

            Pull request #339 updated
            16:23:22 Connecting to https://api.github.com using botaccount/****** (botaccount-github-userpass)
            Checking out git git@github.com:team/project.git into /var/jenkins_home/workspace/team_unilanding_PR-339-QD7W5G5UCQBK3XJQYNPM6GQDRVGPY6TQABV6SD4RWHXU2EDQR65A@script to read Jenkinsfile
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > git config remote.origin.url git@github.com:team/project.git # timeout=10
            Fetching without tags
            Fetching upstream changes from git@github.com:team/project.git
             > git --version # timeout=10
            using GIT_SSH to set credentials botaccount-github-ssh-key
             > git fetch --no-tags --progress git@github.com:team/project.git +refs/pull/339/head:refs/remotes/origin/PR-339 +refs/heads/master:refs/remotes/origin/master
            Merging remotes/origin/master commit bb79fa5bd122fa0fac4608d10a9ccd41dc2e72f7 into PR head commit dc38ea253251ca79a4587c20b25b425ede135de7
             > git config core.sparsecheckout # timeout=10
             > git checkout -f dc38ea253251ca79a4587c20b25b425ede135de7
            
            GitHub has been notified of this commit’s build result
            
            hudson.plugins.git.GitException: Command "git checkout -f dc38ea253251ca79a4587c20b25b425ede135de7" returned status code 128:
            stdout:
            stderr: fatal: reference is not a tree: dc38ea253251ca79a4587c20b25b425ede135de7
            
                at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
                at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:72)
                at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2295)
            Caused: hudson.plugins.git.GitException: Could not checkout dc38ea253251ca79a4587c20b25b425ede135de7
                at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2319)
                at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)
                at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)
                at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1068)
                at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1161)
                at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
                at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:143)
                at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
                at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:295)
                at hudson.model.ResourceController.execute(ResourceController.java:97)
                at hudson.model.Executor.run(Executor.java:429)
            Finished: FAILURE
            

             

            Only closing old PR and re-creating it can solve this problem. Need this fix for GitHub.

            Show
            soar Aleksey Smyrnov added a comment - I've faced same problem today - but with GitHub and it's Pull Requests: Pull request #339 updated 16:23:22 Connecting to https: //api.github.com using botaccount/****** (botaccount-github-userpass) Checking out git git@github.com:team/project.git into / var /jenkins_home/workspace/team_unilanding_PR-339-QD7W5G5UCQBK3XJQYNPM6GQDRVGPY6TQABV6SD4RWHXU2EDQR65A@script to read Jenkinsfile  > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository  > git config remote.origin.url git@github.com:team/project.git # timeout=10 Fetching without tags Fetching upstream changes from git@github.com:team/project.git  > git --version # timeout=10 using GIT_SSH to set credentials botaccount-github-ssh-key  > git fetch --no-tags --progress git@github.com:team/project.git +refs/pull/339/head:refs/remotes/origin/PR-339 +refs/heads/master:refs/remotes/origin/master Merging remotes/origin/master commit bb79fa5bd122fa0fac4608d10a9ccd41dc2e72f7 into PR head commit dc38ea253251ca79a4587c20b25b425ede135de7  > git config core.sparsecheckout # timeout=10  > git checkout -f dc38ea253251ca79a4587c20b25b425ede135de7 GitHub has been notified of this commit’s build result hudson.plugins.git.GitException: Command "git checkout -f dc38ea253251ca79a4587c20b25b425ede135de7" returned status code 128: stdout: stderr: fatal: reference is not a tree: dc38ea253251ca79a4587c20b25b425ede135de7     at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)     at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$800(CliGitAPIImpl.java:72)     at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2295) Caused: hudson.plugins.git.GitException: Could not checkout dc38ea253251ca79a4587c20b25b425ede135de7     at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2319)     at jenkins.plugins.git.MergeWithGitSCMExtension.checkout(MergeWithGitSCMExtension.java:146)     at jenkins.plugins.git.MergeWithGitSCMExtension.decorateRevisionToBuild(MergeWithGitSCMExtension.java:112)     at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:1068)     at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1161)     at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)     at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:143)     at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)     at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:295)     at hudson.model.ResourceController.execute(ResourceController.java:97)     at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE   Only closing old PR and re-creating it can solve this problem. Need this fix for GitHub.
            Hide
            foxylion Jakob Jarosch added a comment -

            What is currently blocking the pull request from being merged?

            Show
            foxylion Jakob Jarosch added a comment - What is currently blocking the pull request from being merged?
            jamesdumay James Dumay made changes -
            Remote Link This issue links to "CloudBees Internal OSS-2697 (Web Link)" [ 20529 ]
            tario Patrick Ruckstuhl made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            tario Patrick Ruckstuhl made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            tario Patrick Ruckstuhl made changes -
            Assignee Patrick Ruckstuhl [ tario ]
            Hide
            feliwir Stephan Vedder added a comment -

            We are hit by this issue aswell. Please fix this issue

            Show
            feliwir Stephan Vedder added a comment - We are hit by this issue aswell. Please fix this issue
            Hide
            kuenmar Markus Künstler added a comment -

            What i don't get:

            • Bitbucket has this lazy-disc-refs behaviour this since 1.3.0
            • we're experiencing this bug only after we  updated bitbucket-branch-source-plugin to 2.2.8

            so why did it work before?

            Show
            kuenmar Markus Künstler added a comment - What i don't get: Bitbucket has this lazy-disc-refs behaviour this since 1.3.0 we're experiencing this bug only after we  updated bitbucket-branch-source-plugin to 2.2.8 so why did it work before?
            Hide
            tario Patrick Ruckstuhl added a comment -

            There is a fix for this in my pr and it's waiting to get merged.

            Show
            tario Patrick Ruckstuhl added a comment - There is a fix for this in my pr and it's waiting to get merged.
            Hide
            mrkita Morgan Kita added a comment -

            Hey Patrick, any idea what's the hold up? At our company there are multiple projects that would immediately benefit from this

            Show
            mrkita Morgan Kita added a comment - Hey Patrick, any idea what's the hold up? At our company there are multiple projects that would immediately benefit from this
            Hide
            tario Patrick Ruckstuhl added a comment -

            Unfortunately no idea. It's waiting forever and was reviewed and approved by multiple people and I think even the main maintainer.

            Show
            tario Patrick Ruckstuhl added a comment - Unfortunately no idea. It's waiting forever and was reviewed and approved by multiple people and I think even the main maintainer.
            Hide
            tkleiber Torsten Kleiber added a comment -

            We need this urgent too!

            Show
            tkleiber Torsten Kleiber added a comment - We need this urgent too!
            Hide
            aairey Andy Airey added a comment - - edited

            Devs were pinged on the github PR, please follow the potential discussion there.

            Comments like #meToo are useless and just generates SPAM, please use the vote button.

            Show
            aairey Andy Airey added a comment - - edited Devs were pinged on the github PR, please follow the potential discussion there. Comments like #meToo are useless and just generates SPAM, please use the vote button.
            Hide
            nickbrown Nicholas Brown added a comment -

            As https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/116 has now been merged and published I guess this ticket can now be marked resolved?

             

            Show
            nickbrown Nicholas Brown added a comment - As https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/116  has now been merged and published I guess this ticket can now be marked resolved?  
            nickbrown Nicholas Brown made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            bartdevriendt Bart Devriendt added a comment -

            I updated the plugin to latest version and followed the steps to reproduce the error.  It still fails with the same error (reference is not a tree)

            Show
            bartdevriendt Bart Devriendt added a comment - I updated the plugin to latest version and followed the steps to reproduce the error.  It still fails with the same error (reference is not a tree)
            bartdevriendt Bart Devriendt made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            bartdevriendt Bart Devriendt added a comment -

            Ok, nevermind, I forgot to enable "call can merge".  Can be closed again !

            Show
            bartdevriendt Bart Devriendt added a comment - Ok, nevermind, I forgot to enable "call can merge".  Can be closed again !
            Hide
            kit Kit Plummer added a comment -

            Can anyone verify that this works in the "wild"?

            Show
            kit Kit Plummer added a comment - Can anyone verify that this works in the "wild"?
            Hide
            tario Patrick Ruckstuhl added a comment -

            Kit Plummer can you verify, that you enabled the option "Call can merge" on the configuration? Per default this is not enabled to keep the same functionality as before.

            Show
            tario Patrick Ruckstuhl added a comment - Kit Plummer can you verify, that you enabled the option "Call can merge" on the configuration? Per default this is not enabled to keep the same functionality as before.
            Hide
            kit Kit Plummer added a comment -

            I've not updated servers yet, opting to wait for confirmation in a release.  Not trying to be a prat, just want to ensure/confirm before we update.

            Show
            kit Kit Plummer added a comment - I've not updated servers yet, opting to wait for confirmation in a release.  Not trying to be a prat, just want to ensure/confirm before we update.
            Hide
            josacu Joan Sanz added a comment -

            I can confirm this fix is working correctly, thanks very much!

            Show
            josacu Joan Sanz added a comment - I can confirm this fix is working correctly, thanks very much!
            tario Patrick Ruckstuhl made changes -
            Resolution Fixed [ 1 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            Hide
            kdberk Kevin de Berk added a comment - - edited

            The fix does not appear to be working for us here. Installed and running version of the Bitbucket Branch Source Plugin plugin is 2.2.12.

            RESOLVED: Was resolved by enabling "Call can merge" on the global jenkins configuration page. See discussion below.

            Show
            kdberk Kevin de Berk added a comment - - edited The fix does not appear to be working for us here. Installed and running version of the Bitbucket Branch Source Plugin plugin is 2.2.12. RESOLVED: Was resolved by enabling "Call can merge" on the global jenkins configuration page. See discussion below.
            Hide
            tario Patrick Ruckstuhl added a comment -

            Kevin de Berk did you enable the "Call Can Merge" in the Bitbucket Endpoints configuration?

            Show
            tario Patrick Ruckstuhl added a comment - Kevin de Berk did you enable the "Call Can Merge" in the Bitbucket Endpoints configuration?
            Hide
            kdberk Kevin de Berk added a comment -

            Sorry, I wasn't aware that action was needed on both jira and bitbucket. I don't have direct access to the bitbucket server, so I'll have to check with the admin.

            Show
            kdberk Kevin de Berk added a comment - Sorry, I wasn't aware that action was needed on both jira and bitbucket. I don't have direct access to the bitbucket server, so I'll have to check with the admin.
            Hide
            tario Patrick Ruckstuhl added a comment -

            I was talking about the config in jenkins.

            Show
            tario Patrick Ruckstuhl added a comment - I was talking about the config in jenkins.
            tario Patrick Ruckstuhl made changes -
            Attachment screenshot-1.png [ 43393 ]
            Hide
            tario Patrick Ruckstuhl added a comment -

            Show
            tario Patrick Ruckstuhl added a comment -
            kdberk Kevin de Berk made changes -
            Hide
            kdberk Kevin de Berk added a comment - - edited

            I have nothing that looks like that. We're using a multibranch project.

            Show
            kdberk Kevin de Berk added a comment - - edited I have nothing that looks like that. We're using a multibranch project.
            Hide
            tario Patrick Ruckstuhl added a comment -

            It's on the global configuration

            Show
            tario Patrick Ruckstuhl added a comment - It's on the global configuration
            Hide
            kdberk Kevin de Berk added a comment -

            It seems to be working now! Thanks for the help and quick response!

            It took me a while before I could find the option that you and other people here were referring to. I don't understand why a google search for "Call can merge" (with quotes!) only generates 2 results, of which one is this page and the other completely irrelevant.

            Show
            kdberk Kevin de Berk added a comment - It seems to be working now! Thanks for the help and quick response! It took me a while before I could find the option that you and other people here were referring to. I don't understand why a google search for "Call can merge" (with quotes!) only generates 2 results, of which one is this page and the other completely irrelevant.
            Hide
            markewaite Mark Waite added a comment -

            It seems that the "Call can merge" selection is only available for Bitbucket Server connections, not for connections to Bitbucket.org. I assume that is because it is not needed when connecting to Bitbucket.org. I was unable to duplicate this bug report with Bitbucket.org.

            Show
            markewaite Mark Waite added a comment - It seems that the "Call can merge" selection is only available for Bitbucket Server connections, not for connections to Bitbucket.org. I assume that is because it is not needed when connecting to Bitbucket.org. I was unable to duplicate this bug report with Bitbucket.org.
            Hide
            damyan Damyan Yordanov added a comment -

            Confirmation: when the "call can merge" is not set, an error message "reference is not a tree" occurrs, when trying to build a PR. Setting the option seems to fix the issue on our internal Bitbucket Server. Thank you!

            Show
            damyan Damyan Yordanov added a comment - Confirmation: when the "call can merge" is not set, an error message "reference is not a tree" occurrs, when trying to build a PR. Setting the option seems to fix the issue on our internal Bitbucket Server. Thank you!
            Hide
            macdrega Joerg Schwaerzler added a comment - - edited

            Not sure whether this is the same issue. But this is the closet ticket I could find.
            For us Bitbucket + Branch Source plugin was working just find - until today. Now for one of our repositories I cannot convince Jenkins to clone the repository correctly ritght after a PR was updated or created.

            Now we always would have to re-trigger each PR build manually in order to get it running. Once triggered automatically the builds won't work (see below).
            Furthermore - other, unrelated jobs which are trying to clone the repository at the very same point in time when the PR is updated and which are not even trying to check out the pull request revision but master (of the same repository) - happen to fail with the very same error messages!

            Not sure whether this would be an issue in Bitbucket or in Jenkins git plugin or Bitbucket branch source plugin. Maybe somebody can comment.

            The error message is either:

            Cloning the remote Git repository
            Cloning with configured refspecs honoured and without tags
            ERROR: Error cloning remote repo 'origin'
            hudson.plugins.git.GitException: Command "git fetch --no-tags --progress https://******* +refs/pull-requests/66/from:refs/remotes/origin/PR-66" returned status code 128:
            stdout: 
            stderr: fatal: Couldn't find remote ref refs/pull-requests/66/from
            

            or something like (using a slightly different refspec):

            git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* +refs/pull-requests/*/merge:refs/remotes/origin/PR-*" returned status code 128:
            stdout: 
            stderr: error: refs/pull-requests/66/from does not point to a valid object!
            error: Could not read 7a99185626f667ab8c34d502417c47e99778e633
            error: Could not read 7a99185626f667ab8c34d502417c47e99778e633
            remote: error: Could not read 7a99185626f667ab8c34d502417c47e99778e633        
            remote: fatal: revision walk setup failed        
            error: git upload-pack: git-pack-objects died with error.
            fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
            remote: aborting due to possible repository corruption on the remote side.
            fatal: protocol error: bad pack header
            

            Curiously the Jenkins can be cloned. However later when it comes to the `checkout scm` resp, git step it won't work.

            Show
            macdrega Joerg Schwaerzler added a comment - - edited Not sure whether this is the same issue. But this is the closet ticket I could find. For us Bitbucket + Branch Source plugin was working just find - until today. Now for one of our repositories I cannot convince Jenkins to clone the repository correctly ritght after a PR was updated or created. Now we always would have to re-trigger each PR build manually in order to get it running. Once triggered automatically the builds won't work (see below). Furthermore - other, unrelated jobs which are trying to clone the repository at the very same point in time when the PR is updated and which are not even trying to check out the pull request revision but master (of the same repository) - happen to fail with the very same error messages ! Not sure whether this would be an issue in Bitbucket or in Jenkins git plugin or Bitbucket branch source plugin. Maybe somebody can comment. The error message is either: Cloning the remote Git repository Cloning with configured refspecs honoured and without tags ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Command "git fetch --no-tags --progress https: //******* +refs/pull-requests/66/from:refs/remotes/origin/PR-66" returned status code 128: stdout: stderr: fatal: Couldn't find remote ref refs/pull-requests/66/from or something like (using a slightly different refspec): git fetch --tags --progress origin +refs/heads /*:refs/remotes/origin/* +refs/pull-requests/*/ merge:refs/remotes/origin/PR-*" returned status code 128: stdout: stderr: error: refs/pull-requests/66/from does not point to a valid object! error: Could not read 7a99185626f667ab8c34d502417c47e99778e633 error: Could not read 7a99185626f667ab8c34d502417c47e99778e633 remote: error: Could not read 7a99185626f667ab8c34d502417c47e99778e633 remote: fatal: revision walk setup failed error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header Curiously the Jenkins can be cloned. However later when it comes to the `checkout scm` resp, git step it won't work.
            Hide
            markewaite Mark Waite added a comment -

            Joerg Schwaerzler it is usually much less effective to request help by updating an existing closed bug report than to ask for help on the mailing lists or in the chat channels. There are far fewer people watching updates to Jenkins bug reports than watch the mailing lists and the chat channels.

            In your case, the messages may indicate that a cache repository on the Jenkins master has been damaged or left in an inconsistent state. You may want to look in the $JENKINS_HOME/caches directory to find the directory which is used as the cache for that job. One technique I've used has been to:

            $ cd $JENKINS_HOME/caches
            $ for repo in *; do (cd $repo && echo ==== $repo && git remote -v | grep fetch); done
            

            That will list the remote repository for each of those cache directories. Remove the directory for the remote repository that is having that problem. The next use of the cache will clone that repository and may be enough to resolve the issue.

            Show
            markewaite Mark Waite added a comment - Joerg Schwaerzler it is usually much less effective to request help by updating an existing closed bug report than to ask for help on the mailing lists or in the chat channels . There are far fewer people watching updates to Jenkins bug reports than watch the mailing lists and the chat channels. In your case, the messages may indicate that a cache repository on the Jenkins master has been damaged or left in an inconsistent state. You may want to look in the $JENKINS_HOME/caches directory to find the directory which is used as the cache for that job. One technique I've used has been to: $ cd $JENKINS_HOME/caches $ for repo in *; do (cd $repo && echo ==== $repo && git remote -v | grep fetch); done That will list the remote repository for each of those cache directories. Remove the directory for the remote repository that is having that problem. The next use of the cache will clone that repository and may be enough to resolve the issue.
            kon Kalle Niemitalo made changes -
            Link This issue relates to JENKINS-61493 [ JENKINS-61493 ]

              People

              Assignee:
              tario Patrick Ruckstuhl
              Reporter:
              mkaulig Michael Kaulig
              Votes:
              44 Vote for this issue
              Watchers:
              54 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: