Please don't rewrite the whole API... Just add an "id" field to all the POSTs. The comment events have "id" fields, but only to the comment, not the pull request it is related to. (Although you can parse it out of the links.)
Without the id fields this feature may as well not exist.
Yeap. I have made an integration to post PR updates to Slack , but it only goes so far as saying stuff like "<Someone> updated a PR", "<Someone> posted a comment on a PR"... :( We have to manually open BitBucket and presume which PR was updated... Please Attlassian, give your public endpoints some more love.
Maybe I'm wrong but this seems like a trivial thing to implement.
Pull request is created = we have the ID
Pull request is updated = SELECT id FROM pull_requests_table WHERE state='OPEN' AND source_repo_and_branch = "repo_and_brnach_that_was_updated" and return an array of IDs of the PRs that have been made to your repo (as you can create multiple PRs with different destinations from a single source branch)
Currently not sure what can you do for cases when the PR is updated as you don't have an ID to know with what PR to work with.
Without the PR id, it makes integration with CI needlessly difficult (or inefficient by having to rely on polling). Github has implemented this for a long time in their API and I'm probably going to advocate for the use of that for an next upcoming project. We have been using Bitbucket for many things over Github because of the unlimited private repos but it is worth the money to pay for Github to get a fully functional API. Sorry for the rant--it's just frustrating how simple issues like this get ignored for well over a year.
@Jonathan Mooring@Marcus Bertrand @zdavis It would be nice if we could get any reponse from dev's. A lot of integrations arn't possible at the moment, and more than a year of no reponse i feel is not really the way to go.
Again one easy feature left without any response.
Guys what are you doing ???
This is not trivial, it's a must have for an API.
This is a simple thing but very important for YOUR CUSTOMERS !
Like the avability to tag from sources. When we see that it's like you don't care of what we wrote.
Can someone from the team at least respond !
If i have to migrate my company to github because your api sucks, i will but as a result of your ignorance about what we say i also will throw all your atlassian app that 'im currently using and my company will choose another "partner" more serious to work with.
Personnaly, i apply one rule for the moment: The title of the pr should be unique, you can enforce that with a post pr creation hook and by checking the existing pr. After that, i parse the open pr and find the id by the title.
It's not the better but it does the job if you can enforce that your pr title are uniques.
I'm thinking about another way like a post creation hook that update the pr description by putting it's id in it but i'm not sure the description is available in all api end point.
To be tested
This, along with a couple of other top-voted long-standing issues, is the reason that I'm in advance stages of evaluating other solutions for my company.
We're currently using Bitbucket, JIRA (cloud), Confluence (cloud), Bamboo (server), and evaluating Crowd (server).
We're paying good money for these products and services, but it looks like Atlassian simply doesn't care about its paying customers.
In case someone's curious, here are the leading options in our evaluation:
I opened a support ticket about this issue with the Bitbucket team yesterday and got a reply a couple of hours later. The guy at support said he would bring it up with the developers but can't make any promises on an ETA. I encourage everyone to open a support ticket too at https://support.atlassian.com/servicedesk/customer/portal/11/create/119 and hopefully Atlassian's developers will see the importance of this getting fixed.
For me the workaround ended up being to save the date from "pullrequest_approve", then do an api request for /pullrequests/activity and looking for items that have an "approve" with the same date. That item then also has a "pullrequest" with an id. It feels like the payload from the original hook could just add the actual "pullrequest" object as well without breaking the existing api.
I haven't tested yet but from the documentation it seems that this has all the information that is needed. And also that POST hook is deprecated.
In the future, you will not be able to create POST or Pull Request POST services from this screen,
as Bitbucket's new and improved webhooks will replace these services. Existing POST services
will continue to function as expected for now.
To create a new webhook, refer to the documentation for Bitbucket's updated webhooks .