Hello, we have encountered an issue(?) with the new 2026.5.1 LTA after migration from 2026.4.1.
Can anyone confirm/reproduce this issue?
Greetings,
Rainer
SonarQube Version: 2026.5.1 (Developer Edition) installed from zip
DevOps Platform: Bitbucket Server / Data Center
Description
When attempting to bind a new or unbound project to Bitbucket Server via Project Settings > General Settings > DevOps Platform Integration, saving the form fails with an HTTP 400 error.
A global Bitbucket configuration named bitbucket exists, is configured with a valid Personal Access Token (PAT), and passes the global Check configuration test successfully. However, the v2 API endpoint used by the UI requires a project/user PAT override rather than falling back to the global token(?)
Steps to Reproduce
Set up a global Bitbucket Data Center integration under Administration > Configuration > DevOps Platform Integrations named bitbucket with a valid PAT.
Open an unbound project (Project Settings > General Settings > DevOps Platform Integration).
Select bitbucket as the configuration name, enter the Project key and Repository slug, and click Save.
Actual Behavior
The browser sends the following request:
HTTP
PUT /api/v2/dop-translation/bound-projects HTTP/1.1
The server responds with 400 Bad Request and the JSON body:
JSON
{"message":"personal access token for 'bitbucket' is missing"}
Expected Behavior
**
Successful API Request:** Clicking Save should send the project key and repository slug to the server, where the backend binds the project using the shared global PAT.
Hello, thanks for the detailed report, I was able to reproduce this on 2026.5.1.
This isn’t a regression introduced in 2026.5.1. The PUT /api/v2/dop-translation/bound-projects endpoint has always required a personal access token set for the individual user performing the bind, via POST /api/alm_integrations/set_pat, separate from the global PAT configured on the DevOps Platform Integration itself. The admin-level “check” button only validates the global PAT (used for things like repo discovery), so it will pass even when the per-user PAT is missing, which is what’s causing the confusing “working integration, failing bind” experience you’re seeing.
To resolve it:
Call POST /api/alm_integrations/set_pat with almSetting=bitbucket and a valid PAT for the user who will be performing the bind (this can also be done via the UI when importing a project from the DevOps platform, which prompts for the PAT before listing repos).
Retry the save/bind. It should go through once that per-user PAT is in place.
This is documented in the endpoint’s own API description (“Requires the ‘Create Projects’ permission and setting a Personal Access Token with api/alm_integrations/set_pat for a user who will be using this endpoint”) but admittedly the UI flow and the 400 error message don’t make that requirement obvious when you already have a working global integration. We’ve seen this same confusion reported before for other DevOps platforms, so I’ll flag it to the team as a UX/docs gap worth revisiting, independent of closing this out as expected behavior.
Let me know if setting the PAT resolves it on your end.
Instead of using curl, I used the UI (“Create Project” → “From Bitbucket Data Center”) to provide the PAT I was then able to successfully save the DevOps Platform Integration settings for the project.
Well, it is a regression. It worked in version 2026.1.5. Just upgraded to 2026.5.1 and we have experienced this exact regression today. (we use bitbucket data center)
I am absolutely sure it used to work, because we have a few administrators that manually configure devsops integration on projects automatically integrated by the sonar maven plugin in our CI, and none of them has ever configured a PAT until today.
Hey @rmontag_ap and @yoooooooooooooo, this is not really a regression, it’s just a new check that is not handled very gracefully. But it is intended. Before this check was added, a user could bind a project to a repository without personally having the permission to do so (meaning, without even having access or visibility on that repository), because this binding action used the org-level PAT. Instead, we want to enforce users to user their own PAT so that they always act within their permissions on that repo.
We have created this ticket to track the UI/UX improvement, so that users have a path out of the error state instead of an opaque error message.
Well, announce it as a bug fix + breaking change in the changelog then, because
works → minor release → does not work out of the box anymore => looks exactly like the definition of regression to me
Another not documented breaking change (AFAIK) in this release : “sonar.validateWebhooks” was set to true by default, even if forced to false before. This has broken our CI
Hey @yoooooooooooooo, I agree that at the very least we could list it in the release notes, yes. When I said that it’s not a regression, I meant it in the sense that it’s not a bug, but I do see your point. I’m going to flag this for the team so that they can consider this, and also in case they have any extra insight to add to the discussion.
About the sonar.validateWebhooks (CC @rmontag_ap and @pst), I see your point too, I’m going to let the discussion happen in the other thread, sounds good?
I was then able to successfully save the DevOps Platform Integration settings for the project.