We made adjustments only to the following section of the Code (Picture 2).
However, the Code Smells section is displaying unrelated parts to this particular modification, as shown in the red box in (Picture 3).
We would like to know how to display only the modified part of the code in Code Smells.
In the top left corner of (Picture 1), it also shows 2.2k New Lines, but we only added 6 lines of code.
How can we achieve a Pass status for the Quality Gate?
We have only made modifications that added 6 lines of code, so how can we meet the requirements for Coverage and Duplications?
Can we define the conditions for a Quality Gate Pass ourselves?
Can you share your analysis log? This is most likely a problem with the (in)correct identification of New Code, and your analysis log should tell the tale.
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
I removing “/d:sonar.verbose=true” does make it work, but if we remove it, how can we generate logs? According to the link you provided earlier, without adding this part, the Jenkins console output still doesn’t provide the crucial information for querying (C# Tests Coverage Report Import [csharp]).
I’ve just taken another look at the guide I sent you too. It incorrectly told you to add sonar.verbose to the end step. It should be added to the begin step instead. I’ve corrected the guide. Sorry for the confusion!
I understand this thread is for those 2 topic for coverage, the highlighted part the keywords “Tests Coverage Report Import” are displayed, but it is uncertain whether the log is fully shown.
Your initial screenshot shows “2.2k New Lines” but the log you’ve provided only shows
10:53:39.223 DEBUG: SCM reported changed lines for 24 files in the branch
Going back to that first picture, we’re looking at a short-lived branch. According to the docs, for a short-lived branch we’re going to see:
the new code consists of all those files which have been modified or added relative to the target branch. Modified files are determined by comparing checksums between the sonar.branch.target branch and the short-lived branch to be analyzed.
Now, that comparison is done locally on the build agent, so it could be a question of the version of master available on the agent for comparison.
But if you only changed 6 files and expect to only see the changes on those 6 files, then it sounds like you want PR analysis rather than short-lived branch analysis. Again, the docs:
Instead, short-lived branch analysis is about analyzing feature and bug-fix branches that are not part of a pull request. These usually occur in projects that, for whatever reason, do not use pull requests at all, but want to achieve the same objective as pull request analysis, namely, ensuring only clean code is merged.
In short, if you already use PRs in your project, then you don’t need short-lived branch analysis. Pull request analysis offers more features (pull request decoration, for example) and requires no configuration. Short-lived branch analysis is only useful in the special case where you want to have (some of) the functionality of pull request analysis, but you do not use PRs in your project workflow.
The diagram below shows the flow branches currently being developed by our team on Git.
We need to update SonarCloud (Long-lived branches: master) every other version, which is actually our Develop Branch.
For example, “sonar.branch.target = master” is our project’s develop branch which is “0627_dev”.
SonarCloud (Short-lived branch) corresponds to our local branch from develop branch,
For example, “0627_dev_TaskA”. When we complete “0627_dev_TaskA”, we trigger the Jenkins flow to create a pull request on BitBucket Cloud, and SonarScanner scans the “0627_dev_TaskA” branch.
Based on document, it seem “short-lived branch analysis” and “pull request analysis” very difference, and we should use pull request analysis instead of short-lived branch analysis.
If we use pull request analysis, we need to integrate BitBucket Cloud’s pipeline with SonarCloud right?
Are there any relevant documents or sample that we can refer to?
Yes, I would recommend using PR analysis instead of short-lived branch analysis. And according to the docs, setting it up shouldn’t be much more involved than the branch analysis configuration you’ve already got.
Are you asking whether it’s required to build, or whether it’s required to use Azure? Because it’s not required to use Azure. But you do need to build for C# analysis.
Yes, my question is whether it’s required to use Azure? I would like to use existing resources, for example, utilize Jenkins to help me build a C# project and perform Pull Request analysis. I need reference examples in this area.
