I, too, would really like to have the ability to delete declined pull requests. We work on a team of several developers, and our workflow is that pull requests in the Open tab are ready to be reviewed. If changes need to be made, the PR is declined and re-opened when changes are ready for review again. However, there are many times that for whatever reason a branch that was once reviewed gets abondoned. Now, that branch is permananatly sitting in the Declined box, so that box can no longer be treated as a list of open issues that still need work. It would be a huge help to be able to permanantly delete items from there.
"Why do you want to delete pull requests?"
Because it is referencing a ticket that is not related to the change. I, as a release Engineer, run into this issue often when developers commit work and push to the wrong branch and then reference another branch and ticket they thought they were working on. Since I can't delete the pull request, the reference stays and the tickets appear to be linked even though they aren't linked or related.
I don't want to misinform, but I believe you should be able to to remove the commit from any branches, decline the PR, and force a git gc to remove the data from BBS. The specifics on how to force the git gc might be more involved - for example you might need to be sure that the commit is no longer in the reflog (which is like Git's recent history of previous commits that a ref pointed to) before git gc will remove the commit. Don't take my word for it though - someone else might be able to comment more authoritatively, or you can probably get better help at support.atlassian.com. I don't want you to break your instance by following my instructions in production, so definitely test it out somewhere non-production and take a backup first (which you might later have to delete if you really want those credentials gone).
All that said - once credentials are compromised, you should definitely stop using them and change the password, regardless of whether you can successfully remove them from the repository. They've been leaked and aren't secure anymore. If you do this, it also makes their removal from the repo less important as well since the credentials are no longer valid. Of course if the leaked data is "names and addresses of all our customers" and not credentials, this suggestion doesn't help - can't change those.
Best of luck, Ryan. Don't hesitate to get help from support if you need it.
I think deleting a pull request is a valid use case. We had an issue where a developer accidently commited a file with sensitive information, and submitted a pull request where that information was visibile to all. It now lives on in a pull request, and we have no way of removing this.
It does help -- I was glad to see that added recently! That said, I'd still love to be able to permanently delete some declinced PRs. In our project with 12 devs, we're now up to about 100 declined PRs that will live in the declined box forever. A handful of those were from before you could change the destination branch after creating a PR, but most are ideas that were started and reviewed, but for one reason or another were declined/abandoned. Would be really nice to have the ability to let Declined tab function as a list of PRs that have not passed code review, but are still actively being worked on. It's easy for them to get lost in the noise as it is now.
heres a quick py script to delete both Pull Requests and Branches from a given repository,
all the necessary API calls are in the script,
With the latest BB, you can delete an Open or Declined Pull Request. But not a Merged Pull Request.
I recent had a user commit sensitive data and then merged a Pull Request. Even after removing all references to the commit, it would not go away. I think this is because it was referenced by the PR.
I finally got the commit to be gc'd by deleting the stash-refs/pull-requests/N directory from the server. Then the commit was able to be pruned by git-gc on the server.
The PR still existed, but it wasn't able to show the commits or diff anymore. It did show an infinite loading circle, but that's okay. The sensitive data is gone.
I understand not wanting to delete Merged PRs, but it seems like you should at least allow the System Admin to do this.
Could be a dangerous hack, but I found that pull request data is located at table `sta_pull_request` within the database, with it's `id` column mapped as foreign keys on other tables with `on delete cascade` except for table `sta_pr_activity`.
So you can (at your own risk. always backup!) remove the undesired merged pull request record from the list by
a) find the row from `sta_pull_request` to be deleted
b) remove rows from `sta_pr_activity` with `pr_id` column matching row id found from above
c) remove row from `sta_pull_request`
Then you could also apply git pruning described above by @Charles Pikscher
We’ve been building a plugin to integrate Bitbucket Server and Jenkins CI, and I’m excited to announce that our alpha is ready to download and install. It lets you seamlessly configure a Jenkins job ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events