Azure Devops project name missing warning after upgrade to DE 8.6

After upgrading to sonarqube DE 8.6 we’re getting the following warnings on all PR’s:

image

However PR decoration and quality gate reporting on azure devops is working perfectly fine.

possibly related to my other topic here: Clarification on pull request decoration docs

But clearly this warning is a bug as project name or repository is not required at all for PR decoration to function.

Hi, the previous behaviour was to use the Azure repo+project name found in the scanner context. For compatibility, this will still work for a couple of SonarQube versions.

The new behaviour is to use SonarQube projects settings, on project ALM Configuration.

If you look at your scanner analysis logs, you should have a warning message as well with a related message.

What reason do you have to change this functionality? We are super happy that it works this way currently, no need to setup ANYTHING in sonarqube. Just works out of the box. New project in source control? Just start a build and a sonarqube project is created, analyzed and result pushed to PR.

You’re adding more work for us with this change, so I would like to know the benefit.

We make extensive use of permission templates and have no need for the ‘import project’ functionality that’s been added. In fact we would like to be able to disable the import project funtionality, as it random generates a project key and thus does not work with the permission templates we use to assign groups to projects…

You guessed right, the reason of this change is to go along with the new “import project” feature, that we call onboarding, that includes the creation of the SQ project + a tutorial to guide new users through the SonarQube configuration of a first project. And it’s not designed for more advanced users.

This new onboarding experience is currently discussed between the SQ dev team and PMs, so I’ll make sure to list this thread and your opinion as insight for the discussion. Thanks for sharing your thoughts, it’s valuable to us.

Now, to help you with the situation you face, one possibility you could use is to do API calls to SQ to set these values for each project, with this endoint. The almSetting key is the one you can retrieve here. You could include this call in your build.

About the new vs old behaviour and the deprecation, no hurries. Our deprecation policy is rather conservative, and the detection of parameters from the scanner will keep working for a while.

Good to hear that there is no rush on the deprecation!

Since it’s only a warning we do not mind, just alerted me to some changed behavior which made me worried for the future. But thanks for the suggestion about using the API.

I assume then that it also explains my questions in the other thread about gitlab. Since gitlab decoration was created later I assume the auto-detection of the correct properties was never built, with the new behavior in mind.

We would love if the more advanced scenario keeps being supported and is extended to gitlab and other ALM’s as well, without it we will have to develop a new way to manage our platform for our sonarqube users and IMO the user experience will not be as good as it is now.

Actually, the exact same patterns apply to Gitlab as well. The first solution we implemented with SonarQube 8.1 relied only on gitlab-runner env variable CI_PROJECT_ID, which is still working right now. And we then moved to SQ project-level configuration with SonarQube 8.2, where we now require the Gitlab project Id. The same warning is displayed if you configured a Gitlab project in 8.1 and did not add the project Id in SQ settings after SQ 8.2.

Thanks for your input!

We were looking for that property! We’ll try that out, thanks!

We just tried it on gitlab and it was not working:

There was no merge request decoration.

yes, it only works if you configured your project in SQ 8.1 (when the project key was not needed), and then upgraded to SQ 8.2+.

If you start using Gitlab after SQ 8.1, there is no way to bypass the mandatory SQ project configuration.

Sorry for the confusion.

Is that also for azure devops? :o

Yes, starting with SQ 8.6 you can’t configure a new project with Azure without adding configuration to SQ UI (or API).

Okay that is unexpected. We have multiple customers using the old way with azure devops. This should IMO have been in the changelog as it literally breaks a feature for us.

Thank you for your help with this, we’re going to have to contact our customers asap now that we know.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

@pierreguillot I’m getting conflicting information now from @Colin_SonarSource here: Pull Requests Analysis and Feedback

So I would love to know who is correct here

Hey, well I’m personally aligned with Colin here. On new SQ projects, you can’t configure a new PR decoration without adding the name/repo information to SQ.

Meaning that, for new projects, you are still required to configure the SQ Pull Request menu, just like before. And starting with SQ 8.6, on these settings, you need to provide the name/repo as well to save the form.

Does that clarify?

But that is not correct. Previously we did not have to setup ANYTHING in sonarqube on the project for pull request decoration. It was not required to setup the pull request menu at all. Only the global setup was required.

Is this still the case then? And if so, will that remain working?

@pierreguillot ping

Meaning that, for new projects, you are still required to configure the SQ Pull Request menu, just like before. And starting with SQ 8.6, on these settings, you need to provide the name/repo as well to save the form.

Bolded part is not how it was before. We were able to use pull request decoration for azure devops without configuring pull request decoration on the project.

What we want is this:

We as sonarqube admins set a global azure devops and/or gitlab PR token.
Teams using our sonarqube create new sonarqube projects from analysis and not from project importer. They do not set any pr decoration settings on the sonarqube project.

PR decoration works because the global config is used for azure devops or gitlab depending on the source of the analysis (should be able to detect since this information is available in the pipeline).

I know this used to be possible for azure devops, and is not possible for gitlab. My remaining questions are:

Does this still work for azure devops for new projects?
Will this remain working for azure devops for old and new projects in the future?

Will this be made possible for gitlab?

Ok, I would like to amend my previous statement, indeed you can still achieve a PR decoration without going to SQ project configuration and configure everything. Sorry for the confusion.

So on Azure, you have two possibilities:

  • Use the currently documented process, have your SQ project Pull Request settings configured (and in that case, you need to specify all parameters, including the name/repo)
    or
  • Have all the parameters in the scanner context, and you will get the warning you mentioned in your first thread.

Yes

Yes, despite the deprecation. This behaviour has been deprecated in 8.6, so it cannot be removed before SonarQube 10.x series (see our deprecation strategy here)

For Gitlab specifically, no it’s not under our radar for LTS 8.x.

What we have though is an objective for 2021 to reduce the friction (time and effort) it takes to setup and analyzes a project. What we have in mind is ease the automation of projects setup, one possible solution being introducing SQ configuration as code in the repo. Not sure that would be the implemented solution, but we are committed to improve the flow for enterprise with a lot of projects to configure.

PS: we listed this community discussion as insight to nurture the internal discussion on this topic :+1:

Thank you for the clarifications :+1:

I would then like to specifically mention that the current way azure devops works is the best case scenario for us as sonarqube admins and the current way gitlab works is kind of the worst case scenario.

Like I said before, we heavily use permission templates for this, which means zero setup time for developers before they can start using sonarqube. We create the permission templates with automation, we create a sonarqube “scan user” and provision a token for this scan user in azure devops and gitlab pipelines. They only have to add the scanner in their pipeline, reference the existing token and provide a project key that matches the template and they are good to go. Sonarqube project will be created from scan by the scan user, permissions will be set up by permission template and pull request decoration will be enabled by global config.

For us this is what frictionless looks like :slight_smile: Look forward to seeing what you guys come up with in the future.