-
Suggestion
-
Resolution: Done
-
None
-
3,096
-
4
-
Issue Summary
On creating a pull request in the Bitbucket UI, the stash-refs/pull-requests/<#> does not immediately get generated. This eventually prevent webhook from triggering the related changes. The stash-refs/pull-requests/<#> only can be seen after clicking on other tabs(Diff or Commits) or page.
Steps to Reproduce
- Create a pull request on Bitbucket Server UI.
- Once the pull request is generated it will automatically redirect to the /projects/PRO02/repos/repo04/pull-requests/2/overview page.
- Back to the local repository in the client machine, run the following command:
git ls-remote
Expected Results
It is expected that stash-refs/pull-requests/<#> is generated after the redirect from creating a pull request, and that git ls-remote shows those refs without having to refresh or direct to different tab/page in pull request UI.
The same works fine on Bitbucket Server ver6.10.1, the following was capture in the atlassian-bitbucket.log:
2020-04-02 13:36:21,561 DEBUG [AtlassianEvent::thread-4] admin @1LEP0HUx816x174x0 1wsgekc 0:0:0:0:0:0:0:1 "POST /projects/PRO02/repos/repo04/pull-requests HTTP/1.1" c.a.s.i.j.i.e.RemoteEventPublisher Publishing remote event: com.atlassian.devstatus.vcs.JiraPullRequestEvent@b5a8ef9[type=CREATE,initiator=com.atlassian.devstatus.EventInitiator@6efd4da9[emails=[admin@admin.com],username=admin,displayName=admin,resource=http://localhost:7990/users/admin,avatar=http://www.gravatar.com/avatar/64e1b8d34f425d19e1ee2ea7236d3028.jpg?s=128&d=mm],issueKeys=[BFJ-2],entity=com.atlassian.devstatus.EventEntity@4458397f[id=<null>,displayId=#2,resource=http://localhost:7990/projects/PRO02/repos/repo04/pull-requests/2],sourceId=<null>,sourceUrl=<null>] 2020-04-02 13:36:21,579 DEBUG [AtlassianEvent::thread-2] admin @1LEP0HUx816x174x0 1wsgekc 0:0:0:0:0:0:0:1 "POST /projects/PRO02/repos/repo04/pull-requests HTTP/1.1" c.a.e.r.impl.RemoteEventListener Queueing RemoteEvent com.atlassian.devstatus.vcs.JiraPullRequestEvent@b5a8ef9[type=CREATE,initiator=com.atlassian.devstatus.EventInitiator@6efd4da9[emails=[admin@admin.com],username=admin,displayName=admin,resource=http://localhost:7990/users/admin,avatar=http://www.gravatar.com/avatar/64e1b8d34f425d19e1ee2ea7236d3028.jpg?s=128&d=mm],issueKeys=[BFJ-2],entity=com.atlassian.devstatus.EventEntity@4458397f[id=<null>,displayId=#2,resource=http://localhost:7990/projects/PRO02/repos/repo04/pull-requests/2],sourceId=<null>,sourceUrl=<null>] 2020-04-02 13:36:21,579 DEBUG [AtlassianEvent::thread-2] admin @1LEP0HUx816x174x0 1wsgekc 0:0:0:0:0:0:0:1 "POST /projects/PRO02/repos/repo04/pull-requests HTTP/1.1" c.a.e.r.impl.RemoteEventDispatcher RemoteEvent com.atlassian.devstatus.vcs.JiraPullRequestEvent@b5a8ef9[type=CREATE,initiator=com.atlassian.devstatus.EventInitiator@6efd4da9[emails=[admin@admin.com],username=admin,displayName=admin,resource=http://localhost:7990/users/admin,avatar=http://www.gravatar.com/avatar/64e1b8d34f425d19e1ee2ea7236d3028.jpg?s=128&d=mm],issueKeys=[BFJ-2],entity=com.atlassian.devstatus.EventEntity@4458397f[id=<null>,displayId=#2,resource=http://localhost:7990/projects/PRO02/repos/repo04/pull-requests/2],sourceId=<null>,sourceUrl=<null>] consumable by [] 2020-04-02 13:36:21,580 DEBUG [AtlassianEvent::thread-2] admin @1LEP0HUx816x174x0 1wsgekc 0:0:0:0:0:0:0:1 "POST /projects/PRO02/repos/repo04/pull-requests HTTP/1.1" c.a.e.r.impl.RemoteEventListener Batch size not exceeded for com.atlassian.devstatus.vcs.JiraPullRequestEvent@b5a8ef9[type=CREATE,initiator=com.atlassian.devstatus.EventInitiator@6efd4da9[emails=[admin@admin.com],username=admin,displayName=admin,resource=http://localhost:7990/users/admin,avatar=http://www.gravatar.com/avatar/64e1b8d34f425d19e1ee2ea7236d3028.jpg?s=128&d=mm],issueKeys=[BFJ-2],entity=com.atlassian.devstatus.EventEntity@4458397f[id=<null>,displayId=#2,resource=http://localhost:7990/projects/PRO02/repos/repo04/pull-requests/2],sourceId=<null>,sourceUrl=<null>] 2020-04-02 13:36:21,749 DEBUG [http-nio-7990-exec-1] admin @1LEP0HUx816x176x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /projects/PRO02/repos/repo04/pull-requests/2/overview HTTP/1.1" c.a.s.i.p.w.f.RequestCacheClientPageDataHandler Context bitbucket.pull-request.related-entities was required already. Ignoring. 2020-04-02 13:36:21,749 DEBUG [http-nio-7990-exec-1] admin @1LEP0HUx816x176x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /projects/PRO02/repos/repo04/pull-requests/2/overview HTTP/1.1" c.a.s.i.p.w.f.RequestCacheClientPageDataHandler Context bitbucket.pull-request.links was required already. Ignoring. 2020-04-02 13:36:21,749 DEBUG [http-nio-7990-exec-1] admin @1LEP0HUx816x176x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /projects/PRO02/repos/repo04/pull-requests/2/overview HTTP/1.1" c.a.s.i.p.w.f.RequestCacheClientPageDataHandler Context bitbucket.pull-request.overview.sections was required already. Ignoring. 2020-04-02 13:36:21,751 DEBUG [http-nio-7990-exec-1] admin @1LEP0HUx816x176x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /projects/PRO02/repos/repo04/pull-requests/2/overview HTTP/1.1" c.a.s.i.p.w.f.RequestCacheClientPageDataHandler Context bitbucket.web.repository.clone.dialog.options was required already. Ignoring. 2020-04-02 13:36:22,534 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 4: Could not resolve stash-refs/pull-requests/2/to directly or from packed-refs 2020-04-02 13:36:22,537 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 4: Could not resolve refs/pull-requests/2/from directly or from packed-refs 2020-04-02 13:36:22,540 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 4: Could not resolve refs/pull-requests/2/merge directly or from packed-refs 2020-04-02 13:36:22,543 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPorcelain 4: Initializing work tree in /home/lucifer/atlassian/application-data/bitbucket-home/6.10.1/tmp/git/repo04-work5654377337427207574 2020-04-02 13:36:22,559 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git init --quiet /home/lucifer/atlassian/application-data/bitbucket-home/6.10.1/tmp/git/repo04-work5654377337427207574 2020-04-02 13:36:22,568 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPorcelain 4: Resetting /home/lucifer/atlassian/application-data/bitbucket-home/6.10.1/tmp/git/repo04-work5654377337427207574 to clean the index 2020-04-02 13:36:22,581 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git reset --quiet a6965612196f15e9c21f70f3a0cb6e53e12d5629 -- 2020-04-02 13:36:22,583 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.scm.git.merge.MergeCommand PRO02/repo04[4]: Merging PRO02/repo04 refs/heads/development -> refs/heads/master in /home/lucifer/atlassian/application-data/bitbucket-home/6.10.1/tmp/git/repo04-work5654377337427207574 2020-04-02 13:36:22,591 DEBUG [http-nio-7990-exec-2] admin @1LEP0HUx816x180x1 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/activities HTTP/1.1" c.a.s.i.p.c.d.DriftCommentUpdateProcessor 4:2@0: No rescopes are pending drift 2020-04-02 13:36:22,603 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git merge -m Automatic merge --no-ff --no-log --allow-unrelated-histories 14b47550df92cc831036119b753e9b39b2466fda 2020-04-02 13:36:22,606 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.scm.git.merge.MergeCommand PRO02/repo04[4]: Fetching successful merge to stash-refs/pull-requests/2/merge from /home/lucifer/atlassian/application-data/bitbucket-home/6.10.1/tmp/git/repo04-work5654377337427207574 2020-04-02 13:36:22,607 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.s.g.f.ObjectFetchStrategy com.atlassian.stash.internal.scm.git.fetch.FetchRequest@43063d1c: Fetching single-repository merge by copying new objects 2020-04-02 13:36:22,624 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git update-ref stash-refs/pull-requests/2/merge b3008999882cf0185513bc7e201c32fe4b5d1dde 2020-04-02 13:36:22,630 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPullRequestPorcelain PRO02/repo04[4]: Pull request 2@0 automatically merged in stash-refs/pull-requests/2/merge as commit b3008999882cf0185513bc7e201c32fe4b5d1dde 2020-04-02 13:36:22,640 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.i.s.g.p.DefaultPullRequestRefHelper PRO02/repo04[4]:2@0: Resolved effective diff from a6965612196f15e9c21f70f3a0cb6e53e12d5629 to b3008999882cf0185513bc7e201c32fe4b5d1dde (CLEAN) 2020-04-02 13:36:22,642 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 4: Could not resolve stash-refs/pull-requests/2/from directly or from packed-refs 2020-04-02 13:36:22,645 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 4: Could not resolve stash-refs/pull-requests/2/from directly or from packed-refs 2020-04-02 13:36:22,659 DEBUG [http-nio-7990-exec-4] admin @1LEP0HUx816x177x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO02/repos/repo04/pull-requests/2/merge HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git update-ref stash-refs/pull-requests/2/from 14b47550df92cc831036119b753e9b39b2466fda 2020-04-02 13:36:22,779 DEBUG [http-nio-7990-exec-8] admin @1LEP0HUx816x182x0 1wsgekc 0:0:0:0:0:0:0:1 "GET /rest/jira/latest/projects/PRO02/repos/repo04/pull-requests/2/issues HTTP/1.1" c.a.bitbucket.scm.BaseCommand Executed /usr/bin/git rev-list --format=%H%x02%P%x02%aN%x02%aE%x02%at%x02%cN%x02%cE%x02%ct --topo-order 14b47550df92cc831036119b753e9b39b2466fda ^a6965612196f15e9c21f70f3a0cb6e53e12d5629 --
Actual Results
After a pull request is created, the merge check still runs but does not create any pull request refs.
2020-04-02 13:27:23,195 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx807x409x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /projects/PRO1/repos/repo02/pull-requests/4/overview HTTP/1.1" c.a.s.i.p.w.f.RequestCacheClientPageDataHandler Context bitbucket.web.repository.clone.dialog.options was required already. Ignoring. 2020-04-02 13:27:23,828 DEBUG [http-nio-7990-exec-9] admin @UXZSPNx807x413x2 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/client-plugins/1.0/client-plugins/items HTTP/1.1" c.a.s.i.i18n.PluginI18nService No values found in any valid locale for key and locales [en_US, en] 2020-04-02 13:27:23,846 DEBUG [http-nio-7990-exec-6] admin @UXZSPNx807x414x1 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/client-plugins/1.0/client-plugins/items HTTP/1.1" c.a.s.i.i18n.PluginI18nService No values found in any valid locale for key and locales [en_US, en] 2020-04-02 13:27:23,851 DEBUG [http-nio-7990-exec-6] admin @UXZSPNx807x414x1 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/client-plugins/1.0/client-plugins/items HTTP/1.1" c.a.s.i.i18n.PluginI18nService No values found in any valid locale for key and locales [en_US, en] 2020-04-02 13:27:23,871 DEBUG [http-nio-7990-exec-1] admin @UXZSPNx807x416x3 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/activities HTTP/1.1" c.a.s.i.p.c.d.DriftCommentUpdateProcessor 1:4@0: No rescopes are pending drift 2020-04-02 13:27:23,873 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve stash-refs/pull-requests/4/to directly or from packed-refs 2020-04-02 13:27:23,877 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPorcelain 1: Initializing work tree in /home/lucifer/atlassian/application-data/bitbucket-home/7.0.1/tmp/git/repo02-work838738412132698775 2020-04-02 13:27:23,891 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPorcelain 1: Resetting /home/lucifer/atlassian/application-data/bitbucket-home/7.0.1/tmp/git/repo02-work838738412132698775 to clean the index 2020-04-02 13:27:23,898 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.i.scm.git.merge.MergeCommand PRO1/repo02[1]: Merging PRO1/repo02 refs/heads/feature/tron-1.1.0 -> refs/heads/master in /home/lucifer/atlassian/application-data/bitbucket-home/7.0.1/tmp/git/repo02-work838738412132698775 2020-04-02 13:27:23,910 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.i.scm.git.merge.MergeCommand PRO1/repo02[1]: Successfully merged PRO1/repo02 refs/heads/feature/tron-1.1.0 -> refs/heads/master. The merge will be discarded as no FetchStrategy was supplied 2020-04-02 13:27:23,913 DEBUG [http-nio-7990-exec-7] admin @UXZSPNx807x411x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/merge HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPullRequestPorcelain PRO1/repo02[1]: Pull request 4@0 merged automatically without conflicts 2020-04-02 13:27:23,937 DEBUG [http-nio-7990-exec-3] admin @UXZSPNx807x417x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/inbox/pull-requests/count HTTP/1.1" c.a.s.i.rest.inbox.InboxResource Retrieving pull request count for user admin 2020-04-02 13:27:24,238 DEBUG [http-nio-7990-exec-9] admin @UXZSPNx807x421x1 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/jira/latest/projects/PRO1/repos/repo02/pull-requests/4/issues HTTP/1.1" c.a.b.i.i.j.DefaultJiraIssueService Bitbucket has not been linked to Jira 2020-04-02 13:28:20,762 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve refs/pull-requests/4/from directly or from packed-refs 2020-04-02 13:28:20,763 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve refs/pull-requests/4/merge directly or from packed-refs 2020-04-02 13:28:20,764 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve stash-refs/pull-requests/4/from directly or from packed-refs 2020-04-02 13:28:20,770 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.i.s.g.p.ShinyGitPullRequestPorcelain PRO1/repo02[1]: Resolved merge-base 9d696badb6d87b325d4c7dbf4ff286f89acbe8df for pull request 4@0 2020-04-02 13:28:20,773 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve stash-refs/pull-requests/4/from directly or from packed-refs 2020-04-02 13:28:20,774 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve stash-refs/pull-requests/4/from directly or from packed-refs 2020-04-02 13:28:20,784 DEBUG [http-nio-7990-exec-8] admin @UXZSPNx808x424x0 2p0ibe 0:0:0:0:0:0:0:1 "GET /rest/api/latest/projects/PRO1/repos/repo02/pull-requests/4/changes HTTP/1.1" c.a.s.internal.scm.git.RawGitAgent 1: Could not resolve refs/pull-requests/4/merge directly or from packed-refs
Workaround
Retrieve the pull request's diff, either using REST or the PullRequestService. This will trigger the refs to be updated. Apps which have workarounds to call PullRequestService.canMerge, ScmPullRequestCommandFactory.tryMerge or make a GET request to $BASE_URL/projects/KEY/repos/slug/pull-requests/ID/merge need to be updated to access the diff instead.
- mentioned in
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page")
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- relates to
-
[BSERV-12284] Eagerly update refs/pull-requests/*/from when a pull request's source branch changes
Hello Bryan,
With recent fix on pull requests refs, could you please also comment on refs/pull-requests/*/merge.
In your previous comment https://jira.atlassian.com/browse/BSERV-12284?focusedCommentId=2389584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2389584
refs/pull-requests/*/merge has been fully removed in 7.0 and will never be created/updated by the system again.
Is it still true that refs/pull-requests/*/merge will not be created by the system again?
Thanks
Jan
Updates to make pull request ref creation deterministic have been merged internally and deployed to our dogfooding and production instances to soak.
The changes were merged too late to be included in Bitbucket Data Center/Server 7.11.0. We've already encountered issues in dogfooding with the new eager processing, so we view soaking as very important for both the scalability and stability of this change. The changes are currently planned for Bitbucket Data Center/Server 7.12.0, which will likely happen in its normal cadence after 7.11.0, which means it should be well-soaked both internally and externally by the time the next LTS is released. (7.12 will not be an LTS.) My apologies for the delay on releasing this, but we want to ensure these eager updates don't cause unexpected issues or excessive load.
Lastly, just to reiterate what I posted previously, we will not backport these changes. 7.12.0 will be the first version to apply deterministic updates and previous releases (like the 7.6 LTS) will not be updated.
Best regards,
Bryan Turner
Atlassian Bitbucket
An update for those seeking more deterministic updates for pull request from refs: I've expanded the scope of another issue we're working on "nearby" in the code to include changes that will make from refs update more consistently and more quickly after new changes are made. It's not yet clear exactly what release the changes will ship in, but I wanted to let everyone know they're actively under development and will ship when they're ready/tested.
Along with that update, and in the spirit of open communication and clarity, I want to note a couple things explicitly:
- These changes will not be backported. The existing behavior is intentional, not a bug, and so work related to it is not eligible for backport.
- These changes will not restore 3-way diffs, and merge refs will still not be created. At this time we have no plans to return to 3-way diffs for pull requests. We also have no plans to make diff behavior configurable, which represents a worst-of-all-worlds option for maintenance and future features.
I'll keep this issue updated as our work progresses, and will note the ship version here when it's confirmed.
Best regards,
Bryan Turner
Atlassian Bitbucket
How quickly can we get this fixed? It's breaking all our pull-request builds. This is very disruptive for all our development teams.
We are delaying upgrade to BB 7 until this is available again since most of our customers use this feature. Either add this back in or alternatively support forward looking merges to verify outcomes of merges prior merges being done. for more complex and distributed and parallel repositories, this is a must be to sustain consistent and green builds of main branches.
Please work on this
Not creating the refs (like refs/pull-requests/4/from) is breaking all our multi-branch pipeline jobs since upgrading to Bitbucket 7
As commented above, plugin https://github.com/Cyanoth/Bitbucket-EagerPR-Updates works around this (verified on a VM with Bitbucket server) but our organisation doesn't allow installation of that plugin.
Please work on the issue:
Since the PR generation take s long time, most of the first Jenkins builds of new Pull Requests fail immediately with the following error:
"stderr: fatal: Couldn't find remote ref refs/pull-requests/<#PR>/from"
@Hamzah I used this plugin to resolve the issue pending an official fix by Atlassian, https://github.com/Cyanoth/Bitbucket-EagerPR-Updates
@Dani It didn't fix it for me unfortunately. Thanks for the suggestion.
@Dani I would have to test on our end to be sure, but I don't think that resolved the situation for us. We have two different Jenkins instances connected to our Bitbucket instance and that setting is already enabled on both those instances where we were originally running into this issue last month.
Not sure this is 100% related but helped us resolve our issue with Jenkins multibranch pipelines and PR checkout from Bitbucket.
My customers are suffering from this issue as well. Jenkins and Bitbucket can't work in our preferred PR merge method together if we have Git LFS enabled.
Example of where you need to access the outcome of an automatic merge is where you are using unit testing or automated testing to validate your pull-requests before you allow the reviewer or developer to merge to a release branch. A Bitbucket automatic merge will pick up a merge conflict and force the developer to fix it but it won't stop the developer from breaking unit tests in another feature area.
Please do eagerly create the pull request branch on PR creation. A lot of tools out there rely on this and this seemingly unpredictable behavior is consuming a lot of people's precious time. In our case it was the pull request build feature for TeamCity CI solution.
brad.rydzewski That's a fair callout. It's worth noting that the article in question doesn't recommend using pull request refs for any other purpose than checking them out on a local developer workstation, and doesn't suggest they can or should be used for CI. The article also includes this note:
Note: As justly noted by several Stash (now called Bitbucket Server) developers the refs I'll demonstrate below are considered undocumented and private and could change anytime.
In that light it's hard to review this as a regression, but all the same I can see how that article might lead someone down the wrong path. I do apologise for the inconvenience and frustration; as much as we've reiterated that pull request refs have never been publicly documented API I can understand why one might want to build from these. If you have any additional input you'd like to share around your use cases we'd love to hear about it!
There was a previous comment claiming these refs were never safe to rely on and never considered a public API. I wanted to point out that using the pull-request ref was documented [1] as the recommended method to fetch a single pull request using refs and many of us have come to rely on this capability. I understand that the Atlassian team views this as a new feature request (and technically that may be correct), however, many customers view this as a regression given the system no longer works as previously documented.
[1] https://www.atlassian.com/git/articles/pull-request-proficiency-fetching-abilities-unlocked
This issue is also a hard hitter for everyone using Concourse CI. All concourse resources we found so far that can be used to build PRs (e.g. https://github.com/emerald-squad/concourse-bitbucket-pullrequest-resource) rely on the problematic refs. For us that means we have to:
- use the aforementioned plugin
- AND fix the concourse resource also
For those looking for a working solution with Jenkins, this might help:
https://www.jenkins.io/blog/2019/12/14/generic-webhook-trigger-plugin/
A quick and dirty solution might be to use this Generic Webhok between Bitbucket and Bitbucket plugin:
- In Bitbucket
- Let Bitbucket invoke Generic Webhook trigger, not Bitbucket plugin
- In Jenkins
- Trigger on webhook, save the entire webhook payload with jsonpath as $
- Invoke Bitbucket API to have the merge reference created
- Invoke the Bitbucket plugin on localhost with the entire webhook payload
A better solution might be to just use the Generic Webhook Trigger plugin =)
We are running into this issue as well. Feature branches do not build anymore and we have a lot of them. This is a significant issue for us. We opened a ticket with Atlassian support.
Using the helpful information from Bryan's previous comments, we created a small plugin that triggers the update of refs/pull-requests/*/from immediately after a pull-request is opened or when the source branch of a pull-request is changed. This is done by calling effective diff.
We've been running this in our production environment for a couple of days with no obvious impact on server performance or any problems. With the exception of a few builds that were using refs/pull-requests/*/merge (which no longer exists in Bitbucket 7+) none of our pipelines or build jobs needed any changes after we updated to Bitbucket 7.1 & had this plugin enabled.
No guarantees, but for anyone looking for a possible answer to this issue until Atlassian release a more permanent improvement, then the source & packaged jar (see tab: Releases) can be found here: https://github.com/Cyanoth/Bitbucket-EagerPR-Updates
I've converted this issue from a bug to a feature suggestion. The system is working as designed, and the current behavior, while not ideal, is the intended behavior. The switch from a 3-way diff to a 2-way diff in Bitbucket Server 7.x has made the issue with timeliness of updates to refs/pull-requests/*/from more obvious, but it did not introduce that behavior. The system has always lazily updated the pull request refs, since they were first introduced in Stash 1.3.
With that said, there are multiple 7.x changes that have greatly exacerbated the potential for delays, which make this behavior more obvious and, for many use cases, more problematic:
- In 6.x and earlier, each time a user clicked between files in a pull request's diff, the system might update the pull request refs. The new pull request UI caches the diff hashes, so clicking between files will no longer trigger updates.
- In 6.x and earlier, when the UI redirects to the overview after creating a new pull request, the mergeability check (used to enable or disable the "Merge" button) would trigger the pull request refs to be created. With 2-way diffs in 7.x the mergeability check no longer fetches the merge's objects into the repository, so it no longer updates pull request refs.
- In 6.x and earlier, running comment drift (the processing which "drifts" comments up or down when lines are added/removed "above" them in the diff, or marks them outdated if the line they're on is updated) would update pull request refs. In 7.x, this may not be the case
- Workarounds applied by some apps/other systems (checking the merge) no longer work; such apps/systems would need to be updated to retrieve the changes or diff in order to trigger pull request refs to update
Please note: There's significant discussion going on about this internally, and hopefully we can make improvements in this area. However, in order to give this issue a chance to get the attention it needs (and deserves, in my opinion), we need to classify it correctly so we can work to get it on the roadmap.
Best regards,
Bryan Turner
Atlassian Bitbucket
People also demand this feature for Bitbucket Cloud (https://jira.atlassian.com/browse/BCLOUD-5814).
As long as refs/pull-requests/*/from is shown by git ls-remote, I think people will continue to write software that depends on it, whether it is documented or not. Perhaps then, it would be better to hide the pull-request refs by default (git config transfer.hideRefs, to stop developers of integrations from depending on them), add a system property to unhide them (to let server administrators keep using previously developed integrations), collect analytics about how many sites set that property, and prominently list this change in release notes.
The transfer.hideRefs configuration was released in Git 1.8.2 (2013-03-13), i.e. between Stash 2.2 (2013-03-05) and Stash 2.3 (2013-03-26). I guess the pull request refs are older than that, and nobody thought to hide them when it became possible.
refs/pull-requests/*/merge has been fully removed in 7.0 and will never be created/updated by the system again. For pull requests that were opened prior to upgrading to 7.x, which have a merge ref, that ref will be removed the first time the pull request is updated (or when it's merged or declined, as ever). With the switch from 3-way diffs (which were built around displaying the merge's diff) to 2-way diffs (which use the common ancestor), the system no longer retains the merges it creates to check mergeability; it runs git merge to see what happens, and discards everything that results. This prevents the accumulation of "unreachable" pull request merge objects in repositories, which can (greatly) slow down clone/fetch/pull/push performance as they build up. Any tool that wishes to build a pull request's merge will need to create that merge on its own, going forward.
Prior to 7.0, because pull request diffs were built around the merge, checking mergeability (which happens automatically after page load when a pull request is created via the UI) would create the public refs/pull-requests entries for that pull request. In 7.x, since the diff is now using the common ancestor and no longer needs the merge, checking mergeability doesn't create any refs. (This is shown in the log snippets above.) Instead, the refs are created when a pull request's diff is viewed. Plugins which are installed in Bitbucket Server can simulate this by either using the PullRequestService to stream the pull request's changes, or (more efficiently), by using ScmService.getPullRequestCommandFactory(pullRequest).effectiveDiff() (which PullRequestService uses under the hood). Remote callers can use rest/api/1.0/projects/KEY/repos/slug/pull-requests/N/changes?limit=1 to do the same. Any of those will ensure refs/pull-requests/*/from is created (or updated) to match the pull request's current state.
I'd wager many webhook apps (or other apps that notify external systems, however they do so) have logic in them for using PullRequestService.canMerge, MergeRequestCheckService.check or ScmPullRequestCommandFactory.tryMerge to try and force pull request refs to be created/updated. (The Post Webhooks for Bitbucket app did, back when it was open source; the source has since been made private, or at least moved off Github, so I'm not sure these days.) Those approaches will not work in 7.x. Instead, such apps need to be updated to use PullRequestService.streamChanges or ScmPullRequestCommandFactory.effectiveDiff to force the from ref to be created/updated. As noted earlier, there is no way in 7.x to get a merge ref.
I'll reiterate here that Bitbucket Server's pull request refs are not API, and have never been considered API, so the way they work is dangerous to rely on. I'll also readily acknowledge that that's hardly a satisfactory answer, to receive or to give, and that it would be nice if it changed. I am not a PM for Bitbucket Server, so I can't say when/if such improvements will hit the roadmap. Perhaps I'll see if I can use some upcoming 20% time to make some improvements. I'm sorry that, at least for the moment, I can't offer better.
Best regards,
Bryan Turner
Atlassian Bitbucket
Does this issue cover only "refs/pull-requests/*/from", or also "refs/pull-requests/*/merge"?
Other issues related to these refs:
BSERV-12198Bitbucket Pull request shows outdated commit hash after pushingBSERV-11953(fixed in 6.8.0) Pull Request refs are not recreated on re-open.BSERV-3469(closed) Pull request references in the Git repository are never removed after merge or decline- JENKINS-61493 Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist
- JENKINS-45997 (resolved on 2018-07-06) BitBucket PRs failing to checkout on initial run after PR updated with new commits
- jenkinsci/bitbucket-branch-source-plugin#287 Pull-Requests no longer working on BitBucket Server 7.0
2433cf33d5d3,
I addressed that specifically in my comment from early February:
I understand there are a variety of reasons why people are hoping the merge ref will be re-added, and I will add that I've had some discussions internally about options for doing so. It's not a simple change, though. 3-way diffs, and the merge that supported them, were removed for a reason. For many reasons. And if we bring the merge ref back it's almost certain people will want it to be eager, like from now is, and that would essentially undo all of the performance benefits of removing 3-way diffs in the first place.
For the moment, in the spirit of openness, I would encourage everyone to plan around the idea that the merge ref will never be re-added.
Best regards,
Bryan Turner
Atlassian Bitbucket