Prescribing Default sonar-project.properties files for different language bindings

SonarQube
,
1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
      • Enterprise Edition Version 8.9.8 (build 54436)
  • how is SonarQube deployed: zip, Docker, Helm
    • Helm
  • what are you trying to achieve
    • Project automation with Backstage configured with default sonar-project.properties
  • what have you tried so far to achieve this
    • We’ve provisioned a loose default for typescript/node services

:wave: Hi there!

I’m part of a Developer Experience team, particularly within our QA / Test Engineering space and we’re looking to bake in SonarQube configuration when devs create new services with Backstage.

This can vary based on a project’s language but for the most part, they can all follow a prescribed format.

That said, the languages we support are:

  • javascript/typescript
  • java (taken care of by tyson / sonar-config gen) but worth exploring
  • python
  • go
  • kotlin
  • swift

Do we know if there are available templates that we can safely assume are usable upon a creation of a new project?

Thanks.

2

Hi,

I’m not aware of Backstage templates. Perhaps someone in the community might have one for you…

But generally what you would do is:

For languages like JavaScript and Go, that last is as simple as cding into the project root and invoking sonar-scanner -Dsonar.host.url=[your SonarQube instance] -Dsonar.login=[analysis token]. For Java it will take a bit more. The docs will give you the particulars.

Note that Swift analysis requires a commercial edition.

 
HTH,
Ann

3

Hi there!

Thanks for getting in touch. Got it - I suppose these wouldn’t necessarily be bespoke to Backstage; rather, we want to have programmatically create the sonar-project.properties file dynamically.

Example:

// pseudo-code

function getSonarPropertiesFile(project) {
  switch (language) {
    case 'javascript': 
      return [
      `sonar.projectKey=foo:${project}`,
      `sonar.ProjectName=foo/${project}`,
      `sonar.language=javascript`,
      'sonar.exclusions=node_modules',
       ...
      ].join('\n')
      break;
      case 'python':
        return [...]
}

Hopefully this kinda make sense? I’m trying to see if there’s recommended defaults or maybe it will just be alright to have the sonarProjectKey and sonar.ProjectName? I suppose it depends on how opinionated we should be.

4

Hi,

First, sonar.language was dropped years and years ago. So no need to set it. Analysis is multi-lingual and the languages in your project will automatically be recognized (unless you have some unusual file extension conventions).

You do need to provide sonar.projectKey. And… other than sonar.host.url, which I assume you’ll set at a higher level, that’s it. Everything else has - we believe - sane defaults.

If there are common exclusions you want to set across projects, there’s a global exclusion you can set via the UI, but the default exclusions for JS/TS include node_modules.

Does that help?

 
Ann

1 Like
5

Hi,

OK - thanks for note on sonar.language, I’ll make sure to inform my team!

You do need to provide sonar.projectKey . And… other than sonar.host.url , which I assume you’ll set at a higher level, that’s it.

Copy that.

If there are common exclusions you want to set across projects, there’s a global exclusion you can set via the UI, but the default exclusions for JS/TS include node_modules .

Yup! I’m aware and I’ll see what we have set globally, that would probably knock out a lot of the defaults we ultimately prescribe.

Thanks again G Ann.

1 Like