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
Related
For some reason, TC is no longer detecting changes to the development branch after we tagged a release. Up until last Friday, there were no tags, and TC had been building fine up until that point. We then added a tag to mark the end of a spring and following that, no changes are picked up by Team City. Triggering a manual run only checks out the same revision that was tagged. I don't see why tagging a release should affect the VCS procedure, given that nothing change there.
Relevant output from build log
[10:18:29][Compute revision for 'app-develop branch'] Upper limit revision: 1ec51e6c701548753678c18c20e24c87a6c189f7
[10:18:29][Compute revision for 'app-develop branch'] Latest commit attached to build configuration: 1ec51e6c701548753678c18c20e24c87a6c189f7
[10:18:29][Compute revision for 'app-develop branch'] Computed revision: 1ec51e6c701548753678c18c20e24c87a6c189f7
When I manually ssh into the CI server and go to the build directory I see that the remote develop branch can be seen, but the local is not updated:
* cf2c86a - (origin/develop) Handle special users when formatting names (67 minutes ago) <Carl-Erik Kopseng>
* 70cadf0 - Fix bug in formatting (82 minutes ago) <Carl-Erik Kopseng>
* 8f24c0d - Move user formatting util over to domain class (83 minutes ago) <Carl-Erik Kopseng>
* 1ec51e6 - (HEAD, tag: sprint-15-demo, develop) Merge pull request #826 from mycomp/nim-605 (7 weeks ago) <Carl-Erik Kopseng>
I'll add another answer, as the one by #Amy seemingly worked in one situation, but not for another project. This other project already had the default branch set to the right (default) value of refs/heads/master.
What finally worked for me was the tedious solution found on the TC community:
Detach the existing VCS root
Create a new one with the exact same settings
Yes, that shouldn't make a difference, but it did.
I suspect the joker of the puzzle might be that we reverted back to a previous configuration last week. That made the build counter incorrect (DB vs config), which might have fuzzed with the concept of historic builds and all that jazz. In any case, certainly a bug from the user perspective.
Set your default branch to refs/heads/develop instead of develop.
I suspect what's happening is it cannot find your default branch, since develop isn't a "valid" branch specification, so it searches for other branches and tags. It finds one, and uses that. This wasn't an issue when no other branches/tags existed.
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.
I am not sure whether i can the problem good explaning. Well we use TFS for our building. And in our VS solution, there is also an installshield setup project.
Well, sometimes our team members forget the increase products' versions that why we want to give the version number automatically generated like 3.7.1.*
so when we build the project, the version of our product dll/exe will be 3.7.1.5655
and let say we've created the following versions
3.7.1.1234
3.7.1.5678
3.7.1.9134
and we gave the product Version 3.7.1.5678 to our customer. And after a while, the customer said that there is a bug in this version and the version number is 3.7.1.5678.
So, as I said earlier, we made the version number format like 3.7.1.* and we commit always like that so the assemblyinfo.cs file will not be changed. and when the customer said that the version 3.7.1.5678 has problem. how can we find the related version what the customer has, in tfs commit. Let say we committed several time in the same day and we cannot see (or i dont know it) where the version number 3.7.1.5678 has been stored.
Well, I need to find the realted commit and work on this time project but i dont cannot know which commit it was.
My question is that how you solve this problem?
I hope i could explain it.
We have TFS Version 16.122.26918.3 and we use mostly Visual Studio 2017
You could find the corresponding build of version number which is 3.7.1.5678.
For a particular build, it's easy to get related changeset/commit.
Then you could pull down that changeset/commit from TFS to your local workspace, and work on the bugs.
Not sure what your build number looks like, it's better to make a part of build number the same as the last version number(5678), like the usage of $(BuildID).
$(BuildID) is an internal immutable ID.
Hi trying to implement TFS for my team (18 members).
I made two branches
1) Main branch
2) Dev branch
We are using Agile.
So there is a sprint every week. And on every Thursday i merge changes from Dev to main Branch.
Each developer works on different user story. if he completes a task and check in all changes (5 files). change set (e.g 62) is generated. But tester reported a bug while unit testing. Developer fix the error and check in 1 file. it generated a new change set (e.g 63).
Problem is when i am merging user story's change to main branch i am confused with which change set to move. (62,63....)
what i do is compare whole project. which is headache some times.
Can some one suggest better way. Or i am missing something? any blog that can help
Thanks
If you have a single DEV branch, that implies that you should be merging the whole branch and all changes to MAIN (not cherry-picking, which is what you seem to be describing).
If you want the flexibility to merge only changesets relating to certain stories/bugs, then you should adopt a different branching pattern such as branch by feature.
You need to change the way that you build and deliver software in order to deliver more successfully.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
What you are describing with picking changesets will consistently and continuously reduce the quality of your product.
If you implement a good definition of done and get your guys working in a team rather than independently you should have working software at the end of each sprint. Just before the Sprint review (just in time) you should merge everything from dev to main maybe using a changset as a watermark. If you have stories in your sprint that go towards features that are not ready yet then you should hide them behind feature flags and ship.
If this sounds to hard, or something that "will not work here", or you think "or product is more complicated than that", then you are likely suffering from significant technical debt and you need to pay that back untill you give your Product Owner the choice to release everything at the end of every sprint.
My scenario is pretty straight-forward. I am working on a long assignment locally on my computer, working off of a code branch from TFS. Along comes the boss, and I need to push through a bug fix. Is there any clean way to change contexts? This long assignment has updated a lot of files, and I want to make sure I implement the bugfix from a clean slate.
If I were using Git, I know what to do: create a new branch from main, fix bug, check in, change back to previous branch, but TFS doesn't really work that way. Any ideas?
If you don't want to commit the changes you 're working on yet, your first step is to shelve them - that's pretty straightforward.The next step is to decide where you 'll be implementing your urgent request. This depends on
How you have set up your branching scheme in source control (see here for a great resource ), &
The line where the error was reported
'Boss'-bugs tend to be reported from Release-Lines, taking this as a given you would have to:
Identify the latest changeset that corresponds to the version your problem was reported
Track this changeset to a version in the branch you can work on (I suppose you can't make changes directly on your release line, right)
Make a branch & implement the change. Your build-environment should ensure that all tests & checks ensure that your issue is fixed & that no others have emerged.
Your next challenge is how you 'll propagate these changes to a new Release - This greatly depends on how you ship software to the customer (Hotfixes? Patches? Service Packs?), as well as the severity of the issue.After you 've settled everything back to normal, unshelve & continue working on your long-term task.