When we run a build in Jenkins, the cloned repository has additional branches for pull-requests associated to commits. In Jenkins we are seeing branches such as origin/pull-requests/23/from.
When we clone the same repository to a developer workstation, the pull-requests branches do NOT appear. For example "git branch --remotes" does NOT show any origin/pull-requests/* branches. However, in Jenkins, the same command will show several origin/pull-requests/* branches.
These origin/pull-requests/* branches are causing issues in Jenkins because the Git plugin is setting GIT_BRANCH to pull-requests/... which is causing a few downstream issues for scripts that expect GIT_BRANCH to be the actual branch within the git repository.
With all that as background, how can we prevent Jenkins from seeing these origin/pull-requests/* branches?
I dunno much about Jenkins, but the refs you're seeing are real refs in Git that exist in the Bitbucket Server home directory. They are placed in a location outside the default set used by Git clients. E.g. if you cat .git/config you'll see a section like:
[remote "origin"] url = ssh://git@domain:7999/proj/repo.git fetch = +refs/heads/*:refs/remotes/origin/*
The +refs/heads/* means your client will only fetch refs within refs/heads. Presumably Jenkins is using a wider pattern that includes refs/pull-requests, and so pulls down those extra refs. If you can modify that configuration form the Jenkins server somehow (I don't know how), it should stop pulling those refs.
Thanks Adam. I have discovered that the job is configured to include these references:
I deleted this configuration item, and no longer have the extra branches.
I am unable to find any documentation that describes this ref. You say this is a real ref in Git. While digging for an answer on this, I fond some other refs such as refs/pull-requests/*/merged.
Could you point me to some documentation describing this.
There aren't really any docs on it. It's an internal implementation detail for the most part, and shouldn't be considered supported/stable (we might change the shape of those refs or remove them at any time). Some people use them to build the merge commits of PRs (that is, not just building the commit on the head of the source branch, but building a commit that is the merge of the source branch into the target). However, those refs aren't always up to date since we lazily calculate them to avoid creating new merge commits every time the target branch changes. You really have to carefully tweak things to get those builds to work out and not build too often or too late. I probably wouldn't recommend it for most use cases.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot