We have our build pipeline set up with Team City (version 2017.1.5) and we use on-premise Bitbucket server (version 4.8) for our git repository. Our branching model is GitHub Flow
We use mendhak Team City plugin to report build status to Bitbucket
server. Additionally, we have created a build in team city to build pull request with branch trigger: +:refs/(pull-requests/*)/merge
.
However, the build status for this branch filter is not visible in the Bitbucket the pull request window/page.
If we use the branch filter on the feature branch (eg. +:refs/heads/(feature/*)
), the build status is shown correctly on the PR. But, we are interested to display PR build status on our Pull Requests.
We found out that there is already an open issue with Atlassian since 2013 (yes - almost 5 years). It looks like it would not be fixed any time soon.
Ask:
Are there any workarounds or Bitbucket plugins (or Team City plugins) available which can solve this issue. We want to avoid adding any additional branch filter/ trigger.
I feel it is fairly common problem and it should have already been solved by many other teams/ individuals. I just not happen to find out right resource/ material.
Any pointers, is highly appreciated.
Updating build status using REST APIOnce settings page is open go to OAuth -> Add consumer. Use a callbackURL. Anything will work. Add read permission to the repository.
On the Pull request page you can see builds information in two locations – you can see the latest build status in the Overview tab, and you can see builds information for each commit in the Builds tab.
To get to your Bitbucket settings, click your avatar in the lower-left corner and select Bitbucket settings.
The problem is that the ref you're using (under refs/pull-request/*
) is internal only, and not visible in the Bitbucket web UI.
Imagine you have a repo on Bitbucket Server like this:
Now suppose you create a PR from "branch" to "master". The refs visible in the Bitbucket Web UI don't change, but a git clone --mirror
reveals the hidden refs/pull-request/*
refs that get created behind the scenes:
git clone --mirror http://vm.bit-booster.com/bitbucket/scm/bb/rebase-example-1.git
cd ./rebase-example-1.git
git log --all --date-order --decorate --graph
Result:
Having Team City or Jenkins or Bamboo or whatever build using refs/pull-requests/1/merge
(e.g., 01ebefda503c
in this example) does have one major advantage compared to only building branch
.
You get to preemptively build the real thing (the merge) before you actually merge. It's like a sneak peek into the future.
But it has one major disadvantage if you then try to publish build-status using that same ref. Commit id 01ebefda503c
is not visible in Bitbucket's Web UI, and so the the pull-request build-status integration won't pick up on the successful (or failed) build.
But there's a nifty workaround. Let Team City (or Jenkins or Bamboo etc) pointlessly push build-status to the preemptive merge, and then use curl
to fire off a copy of that same build-status to HEAD^2, aka 01ebefda503c^2
aka e466842138b65
.
(Background: the caret operator '^' grabs the given parent of the specified commit, e.g., ^1 is 1st parent, ^2 is 2nd parent, and if you're working with crazy people, ^3 would be 3rd parent from an octopus merge, and so on. Personally I have not seen a real octopus merge in the wild in years. Also recall that vast majority of commits only have a single parent, aka "string-of-pearls" style commits. Only merges have 2 or more parents.)
You can fire off a build-status against HEAD^2 like so:
curl --user user:password -H "Content-Type: application/json" -X POST -d \
'{"state":"SUCCESSFUL", "key":"K", "name":"K-9", "url":"http://bit-booster.com/"}' \
http://vm.bit-booster.com/bitbucket/rest/build-status/1.0/commits/e466842138b658a1b09caa0b1caea065194311ce
Then build-status will be visible on the PR.
And checkout my Bitbucket add-on. :-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With