We have a SonarQube 6.0 server with enabled SCM plug-in. So the REST webservice returns the author for each new issue.
While this is an important information, the person who fixed the issue is also important to me. The assignee seems to be that person, however the issues are auto-assigned to whoever created them and their assignee doesn't get changed when somebody else commits a fix. (And yes, the author should fix the issues, but often they don't.)
Things I tried:
Rerun Sonar on a project that was not changed since the SCM plug-in was introduced: the author was filled with the committer, and the assignee was only filled if there is currently a Sonar user with the same name
introduced a new issue - both the assignee and the committer where set to the committer
fixed an issue with an assignee: nothing changed
fixed an issue without an assignee: nothing changed
So from that I assume if I wanted to fix an issue, I had to manually open the Sonar Website, find the project, find the issue, assign it to me, than commit. That's not really acceptable. So I assume there is some other way for Sonar to handle that information.
How do I find out who fixed a Sonar issue?
Unfortunately, you're not going to be able to do this because:
When an issue is created, it's associated with a line in a file, and assigned to its "creator", the last person to touch that line.
When an issue closed, it stays associated to its file, but loses the line association. So there's no way to attach "praise" to a closed issue because we've lost the link between the issue and the person - the line number.
On a side note, you say something about assigning yourself issues on SonarQube before fixing them. Perhaps that was in an attempt to make the "praise" association, but there's no reason to do this.
To the issue of knowing who's not fixing their issues: you can always search by assignee (and/or creator) in the Issues interface. The Issue count and age you see there should give you some idea of what's going on.
Related
On our team, pull requests were often raised with changes similar to the following
(or sometimes they would change back, that is, remove the .git)
This was causing a lot of noise in PRs but we were unable figure out the cause of the change.
We (much) later discovered that this was happening because a member of the team was using AppCode without our knowledge. It is also a known issue:
https://youtrack.jetbrains.com/issue/OC-21297/AppCode-messes-up-the-xcodeproj-project-pbxproj-file-and-introdu
Here's the error I was getting in VS2015: "One or more checked work items failed the transition testing due to invalid field values. Please correct the values and retry the check-in."
I had this when checking in an associated work item and flagging the item as resolved. So
Work item in in progress
Check in with this work item marked as resolved
Work item is updated to ready to test
BUT
the work item can't move into the new state as it needs additional information. In my case TFS is set to assign the bug back to the person that raised it. It was such an old bug that the person raising it had left the company and doesn't exist in TFS - hence the error.
Moral of the story - fix bugs quicker.
In my case, I was forced to do the Associate since I got the error message. When I went into the Work Item in VSTS I manually resolved it and it prompted me to set a required field. Were that required field set, the Resolve from Visual Studio would have worked.
I faced same issue while check in from visual studio.
Change the related work item as associate instead of resolve from visual studio solved my issue.
As a workaround : Create a new task/bug in your VSTS for whichever story. Then assign your check in to that work-item. That's what the error is somewhat saying... Difficult for me to decipher at first, hope this helps others.
You need to determine the task status you have created for your TASK. You should set your task state -- Development or other, You get an error because "state" is "new"
I'm using DevOps 2019 on-prem and I had 1 little update to share.
I created the Bug on the Web Portal and kept it open, added the Ticket Number for the checkin and got the above error.
EASY FIX :
Remove Ticket from Checkin
Close Ticket in Web Portal
Re add Ticket
Checkin
ALL IS GOOD.
Situation
I am running Sonarqube 5.2. Due to changes with how we run Sonarqube via CI, I needed to update my project keys. This is a Maven-based Java project (i.e., submodules). The key changed was to simply add the branch to the key for the parent and all sub-modules. After updating all the keys I ran the new CI job.
Problem
After doing so our unresolved issue count went from 223 to 883. Strangely enough, the projects dashboard still displays 223. However, if click that 223 issue count link to drill into them the number jumps to 883.
If I use the default "My Issues" filter it says I have 74. If I try to navigate/view each one of them I can't get past 11/74 (I click but the paging control just flashes yellow).
What doesn't work
Since I can't delete these mysteriously inaccessible issues I thought I'd mark them all as "Won't Fix". However, attempting this has no impact on the "Unresolved" issues/count. Viewing sonar.log the POST to make the change returns a 200.
Question
Is there anything I am missing within the web application that can address this. Or is there any SQL I can run?
FWIW
I subsequently did the same process for a Javascript project with any issue duplication
In trying to revert things I figured this one out.
The very first time we ran the CI changes we had failed to update the project keys first. In all the attempts to fix via restores/retries all we did was reimport the database backup. The culprit was the Elasticsearch cache. The duplicates only existed in the context of the ES index due to the initial failure to update the keys first.
In the end, I ended up deleting the <sonar>/data/es, restoring the database, updating the project keys, and the running the analysis via CI.
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.
I am using TFS 2012 express. When i try to use get latest version I get so many conflicts(more than 250). When I compare it i found that almost most of the conflicts are due to Case differences. Some times i do i get valid conflicts and which can be manipulated using merge tool. But comparing this lot number of conflicts(more than 250) is very difficult to me. For example in below image you can see changes like MsfgTemp and MSFgtemp(this kind of case differences) . I do get lot of this kind of differences(one more i got is Val and val) . No one has made any changes to those lines actually. But still conflicts are shown. Why this kind of conflicts I get during get latest version? How to solve this?
EDIT:
I have found some thing interesting after some research on it. I did several steps to find reason for it. When i was doing it no other user in my team was using TFS or changing anything.
The server has MsfgTemp(in so many lines of code).
I created new workspace and without changing anything compared with server version. As expected no difference found .
Now I changed some lines of code and saved the project.
Now when I see difference I found lot of differences. All changes are like MsfgTemp and MSFgtemp. Another was val and Val .
So it is sure that the reason is not some one changed or anything else. While saving project something causes these changes. My project is of VB6. I edit projects using Microsoft Visual basic 6.0 only.
So now what may be the reason for this kind of difference and how it can be solved?
You should check the TFS file history or use the annotate option to see who changed those lines and when they were changed.
Since TFS only stores the files it doesn't change the contents you should first find out who checked in the changes and that will lead you to the how and why it changed.
NOTE: from looking at the little bit of code you posted in the example the same variable name is used two lines above in both files without conflict.
TempVar = MSFgtemp.TextMatrix(i, TaxDeductedCol)
the conflict your are noticing just two lines later is for a very similarly named variable but I believe this one is different since it is declared inside the loop, so this might be a bug fix with a poorly named temp variable inside the loop...
TempVar = MsfgTemp.TextMatrix(i, ArrAddColNum(k))