Leak period history rewriting

SonarQube Server / Community Build
,
1

On SonarQube Community Edition 6.7.3-LTS and 7.9.-LTS I have the following use case :

  • I have set sonar.leak.period = previous_version on my project
  • I have Jenkins CI environment to perform SonarQube Analysis on maven project (hosted on gitlab) and before a release build I do a SonarQube analysis with a wait for quality gate step in my jenkins pipeline.
  • In my version history i have 1.0.0, 1.1.0, 1.2.0.

Version 1.2.0 is not deployed in production environment yet and i have an hotfix to release with 1.1.1 version.

So I did a job to do a sonarqube analysis on 1.1.0 tag and don’t break version history.

And then I perform the 1.1.1 release version, but no new line is detected on the leak period.

After several tests I can confirm this behaviour :

If i did 1.1.0 tag analysis and then i commit new code after this and perform 1.1.1 analysis the new lines are well computed.

If i did 1.1.0 tag analysis just before my 1.1.1 release (the hotfix git commit date is before 1.1.0 SonarQube event) there is no new code.

I’m ok, it’s not an issue but is it possible to “rewrite” analysis history and change the date of a version event ?

Furthermore the sonarqube documentation is not very detailed on previous version leak period.

2

Hi,

Welcome to the community!

I guess this is just a question of updating the version string & thus the New Code Period on the main branch, right?

If I’m understanding correctly, you analyzed code changes with a new version stamp and were surprised to not see the changes in that commit marked as new. If I’ve got that right, then your changes kinda fell through the cracks. This is fundamentally about how previous_version works. IIRC, the first analysis with the new version string is set as the baseline for measuring changes. I think the (probably Maven-centric) assumption is that you release 1.0, update your version string & build/analyze one more time before starting work on the next iteration.

Confusing? Sure! That’s why:

  • The UI attempts to disambiguate this slightly
    Selection_999(266)
    That “Since [version]” is supposed to be read as “Since that first analysis where you updated the version string to [version]”
  • We’ve added another option in recent versions
    Selection_999(267)
    Selection_999(267)1103×349 67.8 KB

    This lets you manually (or via your release automation!) set the specific analysis to use as the New Code Period baseline.

You’re not seeing this in your 6.7.3 instance because… it’s old! :joy:. Seriously, it’s way past EOL at this point. You need to upgrade as soon as you can.

 
HTH,
Ann

3

Hi ann,

Thanks for the answer, now all my server are on SonarQube 7.9 LTS.

The things that i wanted to do are:

  • Perform a sonarqube analysis of 1.0.0 git tag of my source code
  • Perform another analysis of my new code contribution
  • See the quality gate status on my new code since previous version (1.0.0).

But if I understand your explanation, if the commit date of my new code is before the 1.0.0 SonarQube analysis date, the new code is not detected.

Is there some way to do that in 7.9-LTS CE ? If not in which SonarQube version is possible to set Specific analysis for new code period ?

4

Hi,

To use the specific analysis baseline, it looks like you’ll have to upgrade past 8.0. Since versions between LTS and Latest aren’t supported, I suggest you jump up to 8.4.2. (Note that 8.5 is expected on the 5th.)

 
HTH,
Ann