We have code in several small repos that are not analyzed by SonarQube, which we want to integrate into a single repo/project that is analyzed by SonarQube already.
The obvious problem we face is the possibility that the existing code could trip the quality gate of the existing repo/project when it’s committed, and then we have to mitigate that. This has happened to us a couple times previously on a much smaller scale, and we are looking to avoid it, while still getting that code under SonarQube analysis in the one project.
Ideally, we’d want this integrated code to start off much like a new project does on a base analysis. That is, it’s not considered “new code”. And as mentioned, ideally we want all the code to be in the same project since the code is being consolidated to simplify things.
How can we safely integrate existing code that is not currently analyzed by SonarQube, into a project that is analyzed by SonarQube without tripping the quality gate?
Is there a best practice or recommended approach for this?
We are using the following:
SonarQube Enterprise 7.9.4 LTS
SonarScanner CLI 4.4.0.2170
The repos in question are all TypeScript/Angular projects.
Hello,
What is the New Code Period configured in that singe repo?
You can most likely find a configuration for the New Code Period that will “reset” the new code, to start at the moment you merge the other repos into that single repo.
The new code period for the project is the default previous_version, and the actual version is pulled from the repo’s Git tags and passed in to the scanner via the sonar.projectVersion parameter as part of the build.
I didn’t think to manually change the new code period. Maybe hard-coding a new version in the SonarQube project’s settings and then running the build that integrates the code from the other repos?
Yes, you could change sonar.projectVersion when analysing the repo with all the other repos merged for the first time. That way the quality gate should never be broken. Sequence would be:
Analyze repo after the merge with new version -> no new code
All subsequent analysis would load again the original version from git tags, so new code would have a fresh start from here on.
You can also set it to start with a specific analysis, however since you can only select existing analysis, you’d probably have the QG red momentarily:
Analyze repo after the merge (a lot of new code and red QG)
Ah, ok this makes sense I think. We’ll test those two scenarios and see what works best. Thank you for the detailed steps.
As a side topic, regarding the first scenario if I understand it correctly, when new code is added and the version changes in the same SonarQube analysis, that new code doesn’t get picked up in the New Code Period?
If so I may need to re-think how our builds are triggered, as the Git tag representing the version is created as part of a release, which of course happens after the SonarQube analysis build step. And that SonarQube analysis build step won’t get triggered again on our long running develop and master branches until code is committed/PRs are merged, which for develop could take several days. Merges to master generally only happen once per sprint, so for that branch new code is essentially never getting added to the New Code Period. Do I understand that correctly?
I guess this means that on a version change, the long-running branches should be re-analyzed even with no new code changes?
Sorry, I made a mistake.
The analysis changing the version is already part of the New Code that started with that version.
Meaning if we have:
Analysis 1, v1
Analysis 2, v2
Analysis 3, v2
Changes in analysis 2 and 3 will be part of the “new code” that started with v2.
So coming back to the original post, I don’t think you have a way to avoid having a red QG momentarily. The first scenario I described in my previous post would look like this:
Analyze repo with the merged code -> failing QG
Change version and analyze it again -> fresh New Code Period with no changed code, green QG
No worries, I was sort of expecting not being able to do it without failing the QG. I didn’t think about changing the version and immediately doing another analysis, that makes it fairly straightforward.
We’ll test it to be sure, but this looks like a reasonable solution.