PR decoration is empty in Project Settings for a new project

SonarQube Server / Community Build
, ,
1

I am trying out SQ Enterprise 8.2, auto-configuration of projects doesn’t work, and the documentation seems vague to me, so I need help.

In SQ Enterprise 7.9, my instance already had an ALM configuration for Bitbucket in the Administrator Settings, and that has been taken over nicely. The token has write permissions, and it is for a normal (non-admin) user. Pull request decoration worked before, even though it’s not for an admin user.

In my test for SQ 8.2, I’ve created a repository in Bitbucket, but found no project automatically created for it in SonarQube. Logs showed nothing. I also tried creating a Bitbucket project, then a repository inside it, still the same, no log messages. After executing an analysis (for a regular build, not for a PR), the project is created in SQ for that repository, but the Pull Request Decoration configuration for that project is still empty.

So I cannot confirm like this, that Pull Request Decoration is automatically configured for new projects. I have not executed a PR build yet, I don’t think I should. Correct me if I’m wrong. What am I missing here? Why can’t I see auto-configuration working? What can I do to fix it?

Previously, for whatever project I needed to analyze, I could just pass properties sonar.pullrequest.bitbucketserver.project, sonar.pullrequest.bitbucketserver.repository to the scanner. Are these properties ignored now? Because after a pull request build, I get a warning in the SQ UI: “Pull request decoration did not happen. Please configure pull request properties in the project administration.”

And the documentation made me ask several other questions:

  • Do I really need an admin user? In 7.9 a regular user worked fine. What difference does it make if I use an admin user?
  • Why is it mentioned that a non-admin user with a read access token is enough for auto-configuration, if an admin user with a write access token is used for pull request decoration? I mean, who would configure both tokens anyway? Or do I really need 2 tokens? Feels too complicated the way it is currently documented.
  • How can I verify that there is no error with my setup? Where are the logs?
  • " f you create a project From a Bitbucket Server repository , SonarQube automatically configures your project settings for Pull Request decoration." ← Are you confusing a repository with a project? Do I really need to create a new project for this, or is it enough if I create a new repository in an existing project? And where to create this project? In SQ or in Bitbucket? If in SQ, how?

And most importantly: now just by upgrading to SQ 8.2, none of my new and existing projects are auto-configured, and my old ways don’t work. This is really a frustrating experience, and a problem that I have to configure hundreds of already existing projects manually! What can I really do? Am I supposed to write a script that configures pull request decoration for each project, with an API call?

Thanks in advance.

2

Hi,

that’s a lot of questions, let’s take them one by one.

yes they are. We now rely on the project settings.

The token you configure for the ALM integration in the admin setting will be used for pull request decoration. So the user’s token needs to have access to all decorated projects. A regular user is fine, as long as this user access every project. We advise to use a technical/admin token to make sure you won’t have any permission issue.

The token you configure in the project creation is the logged-in user’s one, that may not be an admin. If we were to reuse the admin token, we may violate some permission access: the logged-in user in SonarQube does not necessarily have full read permission on the whole BBS instance.

A yellow warning is displayed on SonarQube PR if the decoration failed during the background ask analysis. To have more detailed information, you can watch the compute engine logs, ce.log, during the background task analysis. One of the last step of this task is the PR decoration, so if something is wrong, you will see it here.

SonarQube project = Bitbucket Server repository. BitBucket Server also has a notion of project, which is a set of repositories.

Nope, your settings should have been migrated such that you don’t need to reconfigure things. So something is wrong here. We migrated the “old” project properties of the 7.9 version to dedicated properties in the 8.1 version, with the migration number 3104, that is executed when you upgrade.

To help us troubleshoot this issue, could you please tell us if there are any lines in the project_alm_settings of your database?

Do you have a backup of the 7.9.X version before you upgraded?

4

Thanks for the quick reply.

Yes, I do have a database backup of the 7.9.X version, in which I found only 2 projects in the properties table with sonar.pullrequest.bitbucketserver.project and sonar.pullrequest.bitbucketserver.repository keys defined. Those 2 projects migrated just fine to project_alm_settings, and those settings then appear in the GUI as well. And those 2 projects are .NET projects. We got plenty of Java and other projects too, right now I have clue yet why they seem to work differently. Can these properties be manually filled in the SonarQube GUI in version 7? How are they filled in normally? Is the scanner supposed to do that?

5

Ok so there was no issue with the migration, sorry for the wrong lead.

It appears that your java projects where correctly scanned because you used the sonar.pullrequest.bitbucketserver property, which does not work anymore in 8.X versions. There is no automatic migration path for you: you indeed need to set theses project alm settings for every project through the SonarQube UI (in project settings, alm integration).

If you want to automate this with a script, you can use the api/alm_settings/set_bitbucket_binding API endpoint introduced in 8.1.

7

Oh wait, forget that. I double-checked, and this use case should work. My bad. theses properties have been deprecated, but that should still work with a warning. If this is not working, we will investigate. Are you 100% sure the scanner pass the sonar.pullrequest.bitbucketserver.project property?

Also, how many ALM configured do you have at admin level?

10

(Sorry, I was on holiday.)

Against SonarQube 8.2, I used the following Gradle configuration to check if the mentioned properties are set:

sonarqube {
	properties {
		property 'sonar.scanner.dumpToFile', "${file 's.props'}"
	}
}

And they are:

sonar.pullrequest.bitbucketserver.project=myproject
sonar.pullrequest.bitbucketserver.repository=myrepo

When I remove the sonar.scanner.dumpToFile to perform a real analysis, the GUI still shows empty configuration for Pull Request Decoration for that “myrepo” project. Also, I get the warning in the GUI for the PR branch: “Pull request decoration did not happen. Please configure pull request properties in the project administration.”

Now if I switch to my other SQ 7.9.2 instance, and test a PR build, decoration works, despite of the fact that the GUI shows empty settings for “Integration with Bitbucket Server” on that project.

On SQ 8.2, only Bitbucket is configured as ALM integration (on admin level). The rest are both empty and disabled.

Edit: I tested the build with the SonarScanner Gradle plugin 2.7.1, but 2.8 works exactly the same way too, displaying the warning: “SonarScanner will require Java 11 to run starting in SonarQube 8.x,” which I believe is off-topic here.

11

Hi, @pierreguillot, do you see it as a bug too, what I described above?

12

If you create a project From a Bitbucket Server repository

Now I know what that means in the docs. There is a plus sign in the project view, to the right of the project search field. I suggest linking a relevant page that explains the how when you mention this so it’s clear: I shouldn’t look at the Bitbucket GUI…

The token you configure in the project creation is the logged-in user’s one, that may not be an admin. If we were to reuse the admin token, we may violate some permission access: the logged-in user in SonarQube does not necessarily have full read permission on the whole BBS instance.

That is okay, but that step should be made optional. My company never needed so far to use tokens other than an admin one.There’s no skip button for this.

theses properties have been deprecated, but that should still work with a warning.

I see no warning, and currently sonar.pullrequest.bitbucketserver.* properties do not work anymore for us, which is really bad because now if we want to make sure PR decoration is not broken for many of our projects, we have to either:

  • Configure these settings manually for every project before migrating to SQ 8. This is either tedious for one person or not nice if we ask all our projects to set them for themselves.
  • Or migrate to SQ 8 already, but use the API endpoint instead of passing the sonar scanner properties. Sure, but we have to implement this in our client integrations and let projects know to use the updated integration. Some additional work for us, and still obligation for our projects.

The analysis_properties table should be filled with BB info for all our projects (so the SQ 8 migration process could pick them up), but I was told they are stored for the duration of the short-lived branches, i.e. 30 days currently. If a project hasn’t done a PR in the last 30 days, we can’t get the coordinates this way.

13

Note to self: API docs are here: https://next.sonarqube.com/sonarqube/web_api/api/alm_settings/set_bitbucket_binding

14

Hi @rkrisztian,

We take note of this feedback, thanks

Thanks for your feedback, we know that generating a token is not ideal, and we will consider how and if we improve that.

I’m kind of confused here because you said earlier:

After migration and first PR analysis, that’s normal that the properties are not populated in the project configuration, but your PR decoration should work.

Do you see the PR decoration ? (the link to your Bitbucket Server PR at the top right of the PR in SQ)?

Cheers

16

Sorry for confusing you, let me clarify. Retested on a project that already exists in SQ with no PR decoration settings:

  • No warning on the command line by the Gradle SonarScanner plugin. (Aside from: SonarScanner will require Java 11 to run starting in SonarQube 8.x)
  • 1 warning in the SQ GUI (in the PR view) saying: Pull request decoration did not happen. Please configure pull request properties in the project administration.
  • No Bitbucket link in the PR view at the top right corner.
  • Bitbucket GUI shows nothing about the analysis results.

Retest with PR decoration settings configured for the mentioned test project:

  • Same warning on the command line.
  • No warnings in the PR view.
  • I see a See the PR link in the PR view.
  • Bitbucket GUI shows the SonarQube analysis results.
18

Is it a bug then? Can we expect a fix?

19

Problem is still reproducible using SQ 8.4.1 (and a copy of the DB of the prod instance still being on SQ version 7.9):

  • Bitbucket GUI shows nothing about the analysis results for the PR.
  • 1 warning in the SQ GUI (in the PR view) saying: Pull request decoration did not happen. Please configure pull request properties in the project administration.