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.
Related
We have several hundred SSIS packages in a Visual Studio Integration Services project. When this was originally set up it was configured to encrypt sensitive data in the packages with the user key. This caused some issues for us when the project file was checked out and we had conflicts because, of course, our different developer user keys were different.
We just attempted to change to sensitive data with password. To do that we had to update the project property and then we had to do it for every package manually (I tried looping using dtutil.exe but for some reason it did not work). To build my project I had to open every single package, change the password, and then build the project. After a few hours of this and getting every package updated and saved I was able to build and deploy my packages.
After that I did a commit/push to source control (Azure Git) and when my co-worker did a pull and opened the project they are now unable to build with the same error. If he puts the password in and checks everything in and I pull it back down, I get the error again.
The package and project passwords match, I can build, but when it's pulled down we get the error.
The error is:
"Project consistency check failed. The following inconsistencies were detected:
[package Name] has a different password than the project"
I was able to get around this issue but I was not able to figure out exactly what is occurring. I basically changed my protection level to DontSaveSensitive and made sure all of my passwords and sensitive information were parameterized and passed in using SSIS environment variables.
So after making sure all sensitive data was not saved in the packages I changed the project protection level and the protection level of every package. I changed the packages using this code:
for %f IN (*.dtsx) DO dtutil.exe /file %f /encrypt file;%f;0 /quiet
This changed the setting for the packages but I still received the error when building. I had to open each package, change the protection level property to any other value then back to DontSaveSensitive and then build. Once I did that the items fell out of the error message. After doing that manually for 650+ packages I was able to build. The most important resolution was that once I did a push and my co-worker pulled the changes down, they did not have to edit each package. When I was using encrypt sensitive with password we could not stop it from requiring a change and build on every package.
This is still a bit of a mystery, why dtutil.exe would not just change them without needing to re-build is very frustrating. But this work around ultimately got us past the problem and parameterizing was probably the best practice anyway.
I just had the same issue, my problem was that I was missing to introduce the password in the properties of every package (not only in the project), after doing that I have been able to rebuild the project.
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.
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
I'm running XCode 6.1 and working with a git repo. XCode's source control is turned on, as well as the options Refresh local status automatically and Refresh server status automatically and Add or remove files automatically.
Every 10 seconds or so, xcode shows every file's status as changing to unknown (a question mark). After a bit, they mostly all refresh and show the correct status. This keeps happening over and over.
Why is this happening and how can I stop it?
They look like so:
Question Marks
Normal
Finally I have found the cause of this problem, and thus the solution.
My git repo was checked out on my local machine inside of another git repo by accident. Doing this cause massive confusion to XCode, apparently. Doing a fresh checkout in a different folder fixed the problem.
To resolve this you need to do the following:
Go to Source Control -> Refresh Status.
It should solve your problem.
I am running a new sonar server with one project and one quality profile.
I have a "runner" machine that continuously running full scans (after getting the latest code)
and the developers machines where they would like to run incremental analyses before checking-in.
when running an incremental on the "runner" machine without making any changes I get 0 issues as expected (but I am also getting a lot of "resolved" issues - what is the deal with that? I expected to get 0 new and 0 resolved since I changed NOTHING).
BUT, when running incremental on the developer machine (after getting the latest code) I am getting a huge number of new issues, even though they also made no changes to the code.
to make sure I am not making any mistakes, I used TFS to compare the two project directories (on the runner and on the dev local machines, the folders that the analysis uses) - and proved that both are the same (except for the sonar generated files)
so to sum it up:
what could be the cause for such a behavior?
why would I get resolved issues if I did not make any changes to the code?
could it have anything to do with machine clocks? (i am desperate...)
If you would tell me that there is no change in hell that such a problem can occur, then I would go back and check myself, but I am running such a simple configuration that I don't think that I am missing anything.
Thank you for your help.