Languages of the repository: TypeScript, React (.tsx)
Hey all ,
I’m new to SonarCloud, so apologies if I may be using wrong terminolgy.
My company is using SonarCloud with CircleCI integration successfully for Java and Kotlin projects, and I’m trying to set up a SonarCloud for web application.
We’re building SPA using TypeScript / React. The repository is structured using domain driven architecture, where the engineers of each team are responsible for their directories. We have one CI pipeline based on CircleCI.
We would like to have separate definitions / rules for each team. Example folders signup and login should use rule set “a”, folder component-libarary should follow rule set “b”, folder help-center should use rule set “c”, etc.
Failing to meet rule set standards should fail check and prevent PR from being merged.
So far I’ve tried using monorepo approach, but I was unable to narrow down scan to specific folders. sonar-project.properties must be at the root level of the repository, but then how should I pair rule set with folder? Ideally there could be a sonar-project.properties file in each folder, but I’m not sure to configure that.
If there’s a better way to implement something like this I’ll be happy to hear it.
Okay… yes. That’s true in a … (what’s the opposite of monorepo?) normal context. Really the file needs to be at the project root. In a normal context, that’s the repo root, but in a monorepo context, it’s going to be at the top of the folder. So one file per folder, in the “folder root”.
Hey, in case someone has this issue in the future, here are my findings.
It’s possible to set up multiple SonarCloud projects for single repository, one for each folder. The first project for the repository needs to be set as monorepo in the UI. Subsequent projects should have the monorepo checked already on creation.
In each folder create sonar-project.properties file. No need for properties file in the repository’s root folder. The properties file must contain sonar.projectKey= and sonar.organization= that match the project set in the UI. From there each project can set their own preferences. One sonar cloud token can be used for all projects.
In our case, we wanted to also use coverage. For that we used settings sonar.javascript.lcov.reportPaths=../path/to/coverage/lcov.info. This also required to have the SC jobs running after unit tests finish.
Additionally, we found turning off comments valuable. It must be done in UI - Project page > Administration > General Settings > Pull Request > uncheck the option Enable summary comment as described here. Attempts to configure this in properties file failed.
What was most confusing is to find out which configuration should be set in UI and which in properties file. Ideally configuration should override UI, allowing declarative, more of an infrastructure as code approach.