Pull Request POST hook does not include links to related objects (BB-9535)

Issue #8340 resolved
Frode Aannevik
created an issue

The pull-request id is only included in pullrequest_created.

  • pullrequest_declined
  • pullrequest_unapprove
  • pullrequest_merged
  • pullrequest_updated


Comments (73)

  1. Marius Marais

    Is there any update on this bug?

    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.

  2. Daniel Anechitoaie

    Maybe I'm wrong but this seems like a trivial thing to implement.

    1. Pull request is created = we have the ID
    2. 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.

  3. Ben Keith

    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.

  4. Thomas Einwaller

    it looks like Atlassian is not really interested in improving this because integration with HipChat works ... by fixing this the would help competitors like Slack to improve their integrations

  5. Alex Ng

    Any update on this issue? I think this deserves more than just a 'trivial' priority. Without the pull request ID the hooks other than "pullrequest_created" are useless.

  6. Luiz Filho

    So... Yeah... This is our last month on BitBucket. Just finished migrating everything to GitHub and the price, in my company's case, stayed the same. Good bye, Atlassian. Shame.

  7. d

    Damn, if theres one reason to use github and not bitbucket, this is it! How hard can this be to implement - just anything that lets me identify which repo/ pull request this is for!

  8. Matteo

    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.

  9. Braden Kelley

    Is there at least a workaround for this? I'm trying to see if there's a way I can determine the pull request's ID using the API and maybe the timestamp. No luck so far.

  10. Matteo

    @BradenKelley: 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

  11. Itamar Ostricher

    Dear Bitbucket Atlassian team, where are you?!

    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:

    1. Git hosting - GitHub (maybe GitHub Enterprise).
    2. Continuous integration - Travis-CI (maybe Jenkins).
    3. Identity - whatever integrates well with other products (openldap?).
    4. Knowledge base - We never liked Confluence anyway... Considering Phabricator.
    5. Issue tracking - We never liked JIRA anyway (so we hardly ever use it)... Considering Phabricator.
  12. Braden Kelley

    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.

  13. Daniel Anechitoaie

    FIY: Take a look at using WebHooks instead https://confluence.atlassian.com/display/BITBUCKET/Manage+Webhooks

    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 .
  14. Log in to comment