PR Decoration Broken for Hyphenated Projects

SonarCloud
, , ,
1

Sonarcloud isn’t commenting on PR’s for 2 of our projects, and I noticed these also happen to be the only projects with hyphenated names in our org (“red-arrow” and “minas-tirith”)

  • ALM used: Jira
  • CI system used: Gitlab CI
  • Scanner command used: ./gradlew $GRADLE_OPTS test jacocoRootReport sonarqube
  • Languages of the repository: Java
  • Error observed: the absence of PR decorations (not sure where to look for a stack trace)
  • Steps to reproduce: create a MR for a Gitlab project with a hyphenated name
  • Potential workaround: rename the projects (hopefully another workaround exists given the presence of some hardcoding in various DevOps and integration testing codebases)
4

Hi @bhovan and welcome to our Community!

The hyphenated name for the project should not be an issue. I did a small test and the MR was decorated normally.

Your analysis that failed to be decorated generated results at SonaCloud?
It is possible to provide the analysis id for these scans (also the date when they were executed)? You can get it at Administration->Background Tasks in SonarCloud project visualization.

Thanks!

5

Hi @Alexandre_Holzhey, thanks for your help.

AXT-Z2prj9WX8czuDsmb and AXT6E2dE3_W7ldYXw0YC are some of the latest such analyses.

Also decorations seem to be working for another project named “amazon-guardduty” so please pardon the red herring.

6

Thanks for the information! I looked at the first analysis id and it was not decorated because the project at SonarCloud is not bound to an ALM. Did you proceed with the on boarding feature to get this project into SonarCloud (the “analyze new project” option at the top right)? Or these projects share the same SONAR_TOKEN, without using the on boarding (this feature generate a different token for each project)?

7

Unlike the others, these were pushed to Sonarcloud via a templated ci job. Developers set the project parameters following the pattern in the docs, initial scans error out due to the lack of a token, then I add a project-specific tokens as needed. This is certainly an inefficient way of adding new projects – perhaps it’s the issue for the lack of decorations for these two as well?
Is there a way to set one token for all projects to prevent this issue in the future? We have new, integration-based projects being added on a regular cadence.

9

Yes, that is the reason. PR decorations happens when the projects at SonarCloud are bounded to an ALM. This bounding is created when using the on boarding feature in our UI (“analyze new project”), which take care of this and other things.

Unfortunately, we don’t have support to create this bound after the project was auto provisioned by an CI script (or a manual scan). Actually, this auto provisioning feature is on queue to be disabled (requiring the project to be previously provisioned and bound to an ALM) and when we do it, certainly we will do support for this scenario like yours (CI provisioning) and also bound projects that are not bounded so far.

Meanwhile, could you re-create your projects using the UI, in order to have them properly configured?

10

Thank you @Alexandre_Holzhey recreating them resolved my issue

11

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