Re the default quality gate, strangely, we are unclear of the definition “new code”!
To illustrate, let’s say we change a file by adding new code. Is default sonar quality gate analysis done on only the new lines of code or the whole file?
We are unclear but suspect it is the whole file! I’m being told by colleagues that projects are failing quality gate because files with pre-existing blockers etc. were touched/changed.
Any clarification would be much appreciated.
First, analysis will scan every line of every file.
Let's say
I'm using a recent version of SonarQube
I've set the leak period (this can be configured at the global and project levels) to 30 days
That means that any line of code added or updated within the last 30 days is considered "new" and thus, "in the leak period".
If I make a commit that adds a bug, it's marked as a bug in "new code".
If I change a line with an existing bug but don't fix the bug (Why???) then I have an "old" bug on "new" code. Since the assumption is that you'll "clean as you code" (including fixing the old issues in the code you're working on) no work has been put in to "properly" handling this case.
To define the New Code Period globally go to Administration -> Configuration -> General Settings -> New Code Period:
For project specific settings, go to Administration -> New Code Period on the project:
The SonarQube documentation explains the two modes Previous Version and Number of days.
Related
English is not my first language, and I am a bit rusty, so please bear with me.
When browsing the Sonar analysis for my project, I have the following seemingly incorrect data displayed: the creation date of the issue is not the commit date for this date, and I would like to understand why. It so happens that April 29 at 9:35 is the date of the last analysis on that branch.
My code is managed with git and hosted on GitLab. Sonarqube server is at version 7.9.2.30863.
I made some research and found the following: https://docs.sonarqube.org/latest/user-guide/issues/#header-5.
As far I understand the above page says that all created issues have a creation date equals to the commit date, except if one of the following conditions is true:
first analysis of a project or branch. More on that below. Let me move the rest out of the way first.
When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated). The quality profile used for this analysis was not modified
When SonarQube has just been upgraded (because rule implementations could be smarter now). I know I did not upgrade the server. However, it is difficult for me to prove that the server was not upgraded by someone else. I checked the logs, and all I can say is that the Sonar Qube server was last restarted on 2021/04/26, so a few days before the first ‘faulty’ analysis. Since I believe that an upgrade would force a restart, I can assume this condition I out of the way too.
When the rule is external. I do not know what an external rule is. It seems to be linked to the configuration found under Administration > General Settings > External analyzers. However, it is all empty, so I believe I use no external analyzer, hence no external rules that are checked during an analysis.
Back to the first condition: ‘first analysis of a project or branch.’. This is now the most plausible explanation since all the other conditions are out of the way.
Sonar does not provide much history for short-lived branches, so I had to check my continuous integration pipelines to find out when the previous analysis was on that branch. I found a successful execution a few weeks ago (2021-04-09). Since it was more than a few days ago, could it be that the results of that analysis were somehow purged and that the analysis that took place on April 29 was somehow a ‘first analysis’ again? How to check that?
Conclusion: I still do not know why the date on that issue(and some others too) is wrong. All 'faulty' issues are located on the same file. I would gladly welcome any help.
Thanks in advance!
Is it possible that the old issue was just merged into the branch you are currently analyzing?
I had a situation like this:
Checkout feature A branch in January 2021, chip away at it slowly
Checkout feature B branch in February 2021 - This one contains the issue merge feature B onto main in March 2021
Complete work on feature A, run sonarqube analysis
Merge in main, which contains feature B, run sonarqube analysis
Issue from feature B is reported as being created today instead of March 2021
If you were to merge Feature A back to main and then run analysis on main, the issue from feature B would have the correct date, but any new issues from feature A would be dated as per the analysis date.
sonarqube-9.3.0.51899
In the documentation of the SonarQube issue lifecycle (https://docs.sonarqube.org/display/SONAR/Issue+Lifecycle) one of the two possible resolutions is:
Removed - set automatically when either the related coding rule or the file is no longer available. The rule may not be available either because it has been removed from the profile or because the underlying plugin has been uninstalled. The file could be unavailable because it has been removed from the project, moved to a different location or renamed.
Even after analyzing dozens of commits of an open-source project, in which files were clearly renamed and moved, the Removed count is still zero.
Does anybody understand why this is? Shouldn't the counter increase?
SonarQube detects file move, so when E.G. A.java is moved to B.java, its issues will move with it.
Removed, as described in the docs, is used when the rule no longer applies. Try removing a high issue count rule from your profile and reanalyzing; you should see the Removed number increase.
When you in visual studio 2013/tfs2012 check in your work associated with A task you can either 'associate' or 'resolve' the task. Setting it to 'resolve' Will automatically move the task on the sprint backlog and the kanban board to 'Done'. This is Nice because AS A developer you only need to check in using the correct status and status everywhere is okay :-).
This does not Seem to be the case with work items of type 'Bug' - here I Can only choose 'associate' inside vs2013 and then I also need to manually Enter web access and set the bug to 'done'. So I'm kind of doing the same work twice.
Can I without customizing TFS work item types or the proces template get this bug status set to 'resolved' as it works with 'tasks' today - and how?
It's definitely possible - We use "resolve" with every bug (under the Agile template) because it saves such a lot of time. In pending changes, just associate the bug (type in its work item id, or drag and drop the bug into that area of the pending changes) and then you can either "associate" or "resolve" it. (After which the originator can verify the fix and close it)
I presume you're using a template that doesn't offer this facility - so perhaps diff your template against the standard Agile template and you may find the tweak you need to allow this behaviour. Does the template you are using support the "resolved" state on bugs? Perhaps it is missing?
If it is just that your bug template skips the "resolved" state, then it would be trivial to either rename the equivalent state (perhaps it's just not being picked up by the UI because it's not named correctly or not in the correct group?) or insert a new state using the WIT editor.
It's really not a good idea to set a bug as done on checkin. Has the coder verified that the completed output meets the definition of done? How can they hope to do that before they check in?
A bug, just like a PBI, greys set to done when a Development Team decides as a group that out is complete and that they have met ask quality bars.
In the Scrum template Bugs are product level items that confirm to the DoD. However you would break that bug down into a number of tasks at your sprint planning meeting and they can be resolved. The workflow for a bug is:
1) Bug created by tester as the result of a failing test.
2) Bug accepted into the sprint by the Development Team.
3) Bug broken down into tasks for at least coding and testing work.
4) Coder fixes the bug and resolves their Task. The checkin marks this task as Done.
5) Tester validates the Test Case that proves the bugs existence now passes. They mark their Task as Done.
6) The Development Team meets and assesses the doneness of the Bug against the DoD. If done they mark it as Done.
A bugs flow is different from a task.
A bug is raised (tester / user / Developer)
A Bug is fixed (Developer)
A Bug is Tested (built, Integrated to main build, deployed, Tested by Testers)
A bug is done (signed off by the originator)
is the general flow of a bug, TFS ALM assumes that the fixing and the testing would be done by 2 different roles.
if you want to change this to mirror the task work flow, you would have to alter the template
We also use the Microsoft.VSTS.Actions.Checkin action to transition a bug between Development and QA states. Developers can Associate or Resolve, and Resolve triggers the state change attempt. HOWEVER, if any fields are required in the transition, such as Root Cause, the transition will fail without any error message. This is unfortunate. It would be great if the bug popped open and said "Please enter this field." If required fields are filled in before the checkin, then the state transition happens as expected.
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
I am currently working on Phase 1 of my project and all files are checked into Visual Source safe. How do I version this project as phase 1.
I know if it is a single file we can roll back changes etc.
After I start working on Phase 2. I should be able to get the phase I project and make any changes as required.
Please help
If you want to make changes to both Phase 1 and Phase 2, your only option is to make a copy of the entire project.
If you don't need to go back and make changes to Phase 1 and will only ever need to get the code for it, you can use a label.
VSS has a feature called "Share and Pin". It is the closest thing it has to branching. I've found it to take a long time, slows down access later on, and hard to work with.
But I would suggest starting by looking in the help for that topic.
Introducing Visual SourceSafe
How to: Share and Branch a File