-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins ver. 2.121.3
Bitbucket Branch Source Plugin 2.2.12
Branch API Plugin 2.0.20
Atlassian Bitbucket v5.11.1 (Bitbucket server)
From a pull-request on stash/Bitbucket - I'm trying to fetch the original source-branch. The pull request is from `feature/jenkins_phoenix` -> `master`. I can retrieve the target branch (main) but other methods seem to return the PR-XX pseudo-branch. None of the environment branched
details = checkout(scm); sh "echo ${details.GIT_BRANCH} ${details.CHANGE_TARGET} ${details.CHANGE_ID} ${details.CHANGE_BRANCH} ${details.CHANGE_SOURCE} ${details.CHANGE_FORK}" > PR-63 null null null null null sh "echo ${env.BRANCH_NAME} ${env.CHANGE_TARGET} ${env.CHANGE_ID} ${env.CHANGE_BRANCH} ${env.CHANGE_SOURCE} ${env.CHANGE_FORK}" > PR-63 master 63 PR-63 null null
Multiple stack overflow queries https://stackoverflow.com/questions/49151984 and https://stackoverflow.com/questions/48868953 suggest that CHANGE_BRANCH is the right answer, so I suspect the Bitbucket branch source plugin is not retrieving this correctly.
This set up is using the Bitbucket Team/Project "multibranch" builder.
For this test I have explicitly disabled the option in the git plugin to build against the result of merging the source-branch into the target branch, so the selected commit is indeed exactly from the source-branch.
I do however intend to reinstate the merge-branch in the future - and for my examples I need to know the true branch name that triggered the build, not guess it via git inference.
Full (redacted) env dump attached.
I think this is in essence similar to the abandoned issue JENKINS-41104 that was not resolved.
Let me know if there is more information that you need, or other diagnostics I could dump.
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