Using SonarQube 7.4 Developer and doing analysis with sonar-maven-plugin 3.5.0.1254
Summary
New code is missing from the first analysis done after an initial BASELINE analysis. Doing another analysis appears to fix this. This always happens. This makes it easy to miss quality problems introduced by code changes.
Steps to reproduce
Start with an existing project with New Code Period set to BASELINE.
Do initial analysis for a new long-lived branch with mvn clean install sonar:sonar -Dsonar.branch.name=MYBRANCH -Dsonar.projectVersion=BASELINE
Make a code change.
Do analysis again for the same branch, this time allowing sonar.projectVersion to be set by the plugin from the POM version with mvn clean install sonar:sonar -Dsonar.branch.name=MYBRANCH
At this point the branchās Activity shows correctly the 2 analyses that have been done, but the Overview indicates that the new code is based on the previous version instead of the BASELINE version.
The new code doesnāt appear anywhere in the Measures; however, if I drill down into the Code, I do see the line that I added. So the new code was analyzed, but the analysis does not surface it in the SQ dashboard.
If I make another code change and repeat mvn clean install sonar:sonar -Dsonar.branch.name=MYBRANCH, the new code period will be āsince BASELINEā and the new code will appear in the various measures, etc.
One thing missing from the bug you filed is that the new code is missing from the second analysis. That breaks our ability to detect reduced coverage, smells, etc. I didnāt explicitly test for it, but it probably breaks the quality gates. It definitely fools the Bitbucket plugin merge checks, allowing code with reduced quality metrics to be merged. For us thatās more than a minor issue. Just doing a 3rd analysis isnāt enough to fix it; the only workaround is to make a meaningless code change and then run the 3rd analysis. Thatās not something I want to try to automate.
No new lines to cover appear in the measures tab, but if I drill into the code tab I see the changed files; however, those changed lines donāt have the normal yellow highlighting.
I would post a series of pictures, but new users can post only 1 picture/post, and I donāt have time to tell the picture story across 5 or 6 posts.
In fact I saw this effect when I analyzed changes made locally and not checked in. As soon as I committed, Coverage and Duplications on New Code were calculated. Could that be whatās going on?
This auto-triggered when a PR was created in Bitbucket, so there was never a local build. Our Jenkins build job first runs the BASELINE analysis from the branch targeted by the PR, then it runs the analysis on the code in the PR branch, resulting in 2 analyses that donāt surface the new code in the dashboard.
You shouldnāt need (anymore) to run that baseline analysis. We did some work in 7.4 to correctly detect whatās ānewā. Also, youāre running a Long-Lived Branch analysis for each PR? You realize thatās going to be a lot of cleanup (or scripting), right?
Itās possible that our approach has been colored by earlier SQ versions. We use long-lived branches for PRs because the short-lived branches donāt prevent code coverage deficiencies in new code. I donāt think that changes with SQ 7.4, but I think youāre saying that we donāt need to build a separate BASELINE version in every PR long-lived branch, right?
Our leak period is set to BASELINE and every time we merge to our main branch the build creates a new BASELINE version analysis. Soā¦
When we create a new PR branch with analysis version n, the initial leak period will be against the latest BASELINE version in the main branch?
Then if we make changes in the PR branch with analysis version n+1, the new leak period will be between BASELINE (as it was when the PR branch initial analysis was done) and n+1?
If the above is correct, it would definitely streamline our PR builds.
After the PR is approved, we use the BB plugin merge gate to block reduction in quality metrics. I donāt think that would be impacted by the above practice.
Well, in the context of PRs, SLBs, thatās what Iām saying. in the context of using LLBs insteadā¦ I guess you probably still want to set the baseline in your LLB so you can easily tell what issues got added in the New Code Period (it got renamed in 7.4)
And youāre right about coverage not counting in the state of PRs/SLBs yet. We hope to get real QGs in in 7.6.
That brings things back to my original issue then. Julien said he could reproduce that the new code period doesnāt show as since BASELINE in the dashboard. But he could not reproduce the issue I see with the new code missing from the analysis.
Does this discussion clear up anything so that you can reproduce that part of my issue?
Actually, having re-read previous messages, Iām now thoroughly confused.
Every time you merge to master, all your PR LLBs are updated with a new āBASELINEā analysis of master? Meaning you have multiple, non-consecutive analyses in your LLB history with a āBASELINEā version string?
Each merge to our master branch results in just a single analysis that creates a new BASELINE version in the master branch project.
Creating a new PR LLB results in 2 analyses, both in the PR branch project ā first a BASELINE analysis from rebuilding the master branch code, then a new version analysis from rebuilding the PR branch code. We never do another BASELINE analysis after that first one in a PR branch.
Each additional commit to a PR branch results in a new version analysis in the PR branch project from building the code for that commit.
I canāt think of any reasonable way to leverage your donāt-switch-branches-between-analyses observation into a workaround for our automated SQ analysis in Jenkins.
In long lived branches, the detection of new code works by comparing, for each line of source code, the last change date reported by the SCM with the date when the leak period started.
In your case:
The start of the leak period is the time you first created the branch in SonarQube (first analysis)
In the second analysis, the code in the branch is actually analyzed, and the dates reported by the SCM for each line will never be more recent that the date of the last commit to that branch.
Since this process is auto-triggered by your CI, I assume that the last commit in the branch predates the creation of the branch in SQ, which results in all lines be considered as not new.
