Angular monorepo with Nwrl Nx Affected test reports to SonarQube

Basic situation:
Angular monorepo using Nwrl/Nx workspace to selectively test only the projects that had code changes. Then upload those reports to SonarQube in a Github action/workflow.

Which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension):

  • SonarQube 8.8 build 42792 - Developer Edition
  • sonarqube-scanner npm package
  • jest-sonar 0.2.4 npm package
  • @nwrl/jest 10.3.2 npm package

What are you trying to achieve:

  • I’m trying to understand how best to report results (currently using javascript.lcov.reportPaths and testExecutionReportPaths in a sonar-project.properties file) for only those projects that were affected by a change. Nwrl/nx allows you to test, lint, build, etc. only those projects that had altered code somewhere in its dependency tree. The report paths don’t allow wildcards, and Sonar will error if it can’t find a report file that I said should be there (based on that properties file).
  • The analysis should run on PR branches and when merges occur into main. This is done via Github actions/workflow

What have you tried so far to achieve this:

  • For the time being, I am not utilized the nx affected functionality, so all of the tests run. I also hard coded the paths to each of the apps/libraries in the sonar-project.properties file. To get selective tests running with Sonar, I guess I might be able to find a way to determine which projects in the monorepo were tested, determine the report path(s), and then pass those via commandline to Sonarqube. Hopefully there is a smoother way to do that or avoid doing that?

Any help/tips/etc. would be appreciated

Hi,

Welcome to the community!

I’m not familiar with @nwrl. Could you be more explicit about how this works (is supposed to work)?

 
Ann

Thanks! And sure, not a problem.

@nrwl/nx will organize your angular monorepo into what they refer to as a workspace. There’s not much to describe about that for the intents and purposes of my question. Just know that it’s an angular codebase divided into several apps and several libraries. What @nwrl/nx will do though, is give you the ability to run angular architect targets for only the projects affected by a change.

So, let’s say that I have apps A, B, and C. That same codebase has corresponding libraries L-A, L-B, and L-C. If I modify L-C and run nx affected:test, it will only test app C and library L-C. The other apps and projects won’t be tested because nx analyzed the workspace and determined that the changes won’t affect those apps and libraries.

Currently, to report test results to SonarQube, there is one sonar-project.properties file in the root. I have to specify every test result file path in the sonar.testExecutionReportPaths property, since it doesn’t accept wildcards. However, if I specify the test report path for every app and lib, SonarQube will expect to find those files. But if I only selectively run tests (as I described above) only some of the files will exist.

What’s the best way to tell SonarQube to only look for test results and coverage reports for the projects that were affected by a change? Accepting a wildcard would be nice, but outside of that, having SonarQube analysis not fail when coming across a missing file might work. Other than those options, I guess I’d have to determine the test result paths dynamically and pass those in when running the scan via the cli in our pipeline?

Does that help?

Hi,

Thanks for the explanation. It helps.

At this point I have a fiduciary duty to point out that Enterprise Edition($$) includes monorepo support.
And now back to our regularly scheduled programming…

What you’re running into is our fail-fast philosophy: You thought there were going to be reports to include in analysis. There aren't. Something's wrong! Stop!!!

I believe that the analyzer will interpolate env vars. So maybe your best course here is to populate a report list into the env and use that variable in your analysis properties.

At any rate, there’s no way to turn off fail-fast, so you’re going to have to get clever.

 
:woman_shrugging:
Ann

Haha ok, I assumed that might be the case. Oh well, thanks for the info though.

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