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.

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

Here is the corresponding bug report on the Bitbucket JIRA:

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

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.

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"

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.

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

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

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.

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.

I think justinwojo 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

Created https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/116 with exactly this

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.

What is currently blocking the pull request from being merged?

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

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?

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

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

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

We need this urgent too!

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.

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?

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)

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

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

kit 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.

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.

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

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.

kdberk did you enable the "Call Can Merge" in the Bitbucket Endpoints configuration?

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.

I was talking about the config in jenkins.

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

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.

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.

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!

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.

macdrega 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.