-
Bug
-
Resolution: Fixed
-
Critical
-
None
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 setand pushwith force flagEdit: 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.
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
JENKINS-61493 Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist
-
- Open
-
-
-
- Resolved
-
- links to
(1 relates to, 2 links to)
[JENKINS-45997] BitBucket PRs failing to checkout on initial run after PR updated with new commits
Michael Kaulig
created issue -
Michael Kaulig
made changes -
| Description |
Original:
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} |
New:
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} |
Michael Kaulig
made changes -
| Summary | Original: PRs failing after force push | New: PRs failing after update |
Michael Kaulig
made changes -
| Summary | Original: PRs failing after update | New: PRs failing on update |
Michael Kaulig
made changes -
| Description |
Original:
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} |
New:
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} |
Michael Kaulig
made changes -
| Priority | Original: Major [ 3 ] | New: Critical [ 2 ] |
Matthias Muth
added a comment - Same here. This is a huge problem for our CI pipeline 
jay hendren
added a comment - 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":
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.
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. 
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.