Sonarqube issues view shows only violations against top 15 rules, Is there a way I could see a list of all rules with issues count.
Both ProjectIssueFilter and IssueFilter show only 15 issues in the view. The filter shows this message "Only the first 15 results are displayed". Is there a way to see the complete list?
No, it is not possible to see more rules (writing at the time of SonarQube 6.1). It is planned to be improved. You can vote and follow the ticket https://jira.sonarsource.com/browse/SONAR-6400.
A trick I use to see more rules:
filter on Directory and/or Files.
You can sometimes see more rules, which was previously not visible.
Select the previously hidden rule(s).
Remove the filter on Directory and/or Files
You will still see the hidden rules with all the occurrences
It's a bit a pain, but it works...
Related
I want to use SonarQube on my project. The project is quite a big and scanning whole files take much time. Is it possible to scan only changed files in the last commit, and provide report based only on changed lines of code?
I want to check if added or modified lines make the project quality worst and I don't care about old code.
For example, if person A created a file with 9 bugs and then commited changes - the report and quality gate should show 9 bugs. Then person B edited the same file adding few lines containing 2 additional bugs, then commited changes - the report should show the 2 last bugs and quality gate should be executed on the last changes (so should consider the last 2 bugs)
I was able to narrow scan to only changed files in the last commit- but report is generated based on whole files. I had an idea about cutting only changed lines of code, paste them to new file and run sonar scan on the file - but I'm almost sure the SonarQube needs the whole context of file.
Is it possible to somehow achieve my usecase ?
No, it is impossible. I saw a lot of similar questions. These are answers to two of them:
New Code analysis only:
G Ann Campbell:
Analysis will always include all code. Why? Why take the time to
analyze all of it when only a file or two has been changed? Because
any given change can have far-reaching effects. I’ll give you two
examples:
I check in a change that deprecates a much-used method. Suddenly,
issues about the use of deprecated code should be raised all over the
project, but because I only analyzed that one file, no new issues were
raised.
I modify a much-used method to return null in some cases. Suddenly all
the methods that dereference the returned value without first
null-checking it are at risk of NullPointerExceptions. But only the
one file that I changed was analyzed, so none of those “Possible NPE”
issues are raised. Worse, they won’t be raised until after each
individual file happens to be touched.
And that’s why all files are included in each analysis.
I want sonar analysis on newly checkin code:
G Ann Campbell:
First, the SonarQube interface and default Quality Gate are designed to help you focus
on the New Code Period. You can’t keep analysis from picking up those
old issues, but you can decide to only pay attention to issues raised
on newly-changed code. That means you would essentially ignore the
issues on the left side of the project homepage with a white
background and focus instead on the New Code values over the yellow
background on the right. We call this Fixing the Leak, or
alternately Clean as You Code.
Second, if you have a commercial edition, then branch and PR analysis
are available to you. With Short-Lived Branch (SLB) and PR analysis
still covers all files, but all that’s reported in the UI is what’s
changed in the PR / SLB.
Ideally, you’ll combine both of these things to make sure your new
code stays clean.
The position in this matter has not changed over the last years, so don't expect it will be changed.
Summary:
The ultimate use for this workbook is to be able to build a components or bill of materials list. The difficulty comes into play because it is desired to be able to start with any component type and start narrowing down your options on other compatible components to ultimately build a product.
Every component option has it's own rules about which other component options that it is able to interface with. Options within the same component group are mutually exclusive and will never be used together. Each component type will always have one option chosen.
My Attempts:
Doing a bit of research on the www, I started with trying to create lists for the component options. I keep getting stuck with the rules of compatibility. I chose to call out "0" for component options that are compatible so that I could run a check to see if the sum of parts was greater than 0 (aka something wasn't compatible).
I also was starting down the path of using pull down lists under the Data Validation tools, but had trouble when it came to all of the restrictions.
Thank you in advance for any input. I would be happy to elaborate on any part of this request.
An example of how the output might look would be to have the options as pull-downs, but filtered out to not allow you to choose any option that isn't compatible with the other choices that you have already made. Here is an attempt to capture that.
example of output table
I'm using SonarQube 5.3 and it seems that the issue count is different depending on the view I use.
Consider this pic:
if I look in Dashboards -> Issues I see
the numbers on the top left
if I click the grand total (267,877) I end up in the Issues dashboard where I see totally different numbers (bottom right)
Even on the main dashboard I see conflicting data (pic)
Why don't the numbers match? Am I missing something?
There is a difference between Measures and queries run on Issues : measures are collected during analysis time and stay like this until the next analysis. Queries on Issues are updated in real-time according to the changes you do on Issues.
From what I see, we can suppose the 267K Issues is correct and you have some trouble in your SearchServer stack preventing it to be up to date.
You have to check in your sonar.log for ElasticSearch errors and be sure to have enough free disk space available on SQ_HOME/data/es to store and update your Issues.
What you can also do to confirm this, is to stop your SQ Server, clean the data/es directory and restart your SQ. Data should be consistent after that.
Is there a way of changing the default sort in Gitlab issues tracker from "Newest" to "Recently Updated"?
I understand I can change it by just selecting the sort filter, however, doing this every time becomes annoying quickly.
does anyone know if there is a way of changing the default sort in Gitlab issues tracker from "Newest" to "Recently Updated"
Not that I know of (mid 2014):
there is no issue in the GitLab CE project
the one issue in GitHub GitLab project (April 2014) refers to the GitLab CE project
There are a few suggestions, but none regarding the default sorting order
there is nothing in the main config gitlab.yml file
That could be a good PR (Pull Request) to make, starting with:
app/helpers/issues_helper.rb, which sorts issues by name
app/models/project.rb, which also sorts issues by name
app/views/projects/issues/_issue.html.haml which lists issues by name
Update January 2016: as mentioned by stevenw00 in the comments, there is now issue 5546
As a user frequently viewing a list of issues (or merge requests), I want to be able to have the list sort I use remembered, so that I do not have to constantly set the sort when ever I view a list of issues (or merge requests).
Update Dec. 2018 with GitLab 11.6
Per-user saved sort order in issues, merge requests, and epics
There are now user-specified sort order selections in issues, merge requests, epics, and even roadmap views.
Which type of attribute you choose to sort by, and in which order you choose to sort (ascending or descending), is saved to the system, so that when you return to the same type of object list, it will remain what you have selected previously.
Update August 2019, GitLab 12.2
Manual Issue List Sorting
As of 12.2, you can now sort an Issue List in Manual mode, which allows you to drag and drop Issues within the list to assign them a relative order.
The order is persisted and maintained across the entire instance for all Project Issue Lists and Group Issue Lists that have Manual mode enabled
See documentation and issue.
With GitLab 13.7 (December 2020), you have a new (non-free) option:
Sort issues by the number of issues they are blocking
While prioritizing a list of issues in GitLab, it’s often important to determine the critical path and whether an issue is blocking other issues.
With the current issue list, it is impossible to see which issues are blocking other issues. The only way to do so is to open each one and see the list of blockers below the issue description, which is a very time-consuming task!
As of 13.7, you can now use the filter for “Blocking” on any issue list, and you will see a list sorted by the number of blockers.
https://about.gitlab.com/images/13_7/sort-issues-by-blockers.png -- Sort issues by the number of issues they are blocking
See Documentation and Issue.
So, I found a couple of things.
Modified the following file:
app/controllers/projects/issues_controller.rb
On line 29, change from:
sort_param = params[:sort] || 'newest'
Change to:
sort_param = params[:sort] || 'recently_updated'
Modified the following file:
app/views/shared/_sort_dropdown.html.haml
On line 7, change from:
Newest
Change to:
Recently updated
However, still have an issue, it now shows Recently updated as the default option in the menu, however, it doesn't actually apply the sort. They still sort by default as newest.
Any further opinions :S
We are using VSTS2010 for logging bugs. There are weekly builds happening and the QA/DEV updates bugs to fixed/open based on build numbers.
Since there are weekly builds happening and each build has a different number, there are chances for QA/DEV to set incorrect build numbers in fixed build/tested build number.
Questions:
Is it possible to validate the build number values based on some parameters like date of fixes?
Is it possible to show approrpiate messages for the validations?
I don't think there is a build-in way to validate the build number against parameters.
At the moment I can see two possible solutions for your problem, depending on the structure and your possibilities to change the system:
Minimize the set of build numbers to choose. You could change the source list of the build field to show a list with less entries, like only the entries of the last week/month. That would need a little script, that changes your globallist. Of course that only works, if no one else needs to select older builds.
Create an invisible custom control and add it to your bug work item. Inside the custom control you have almost any freedom to change or validate date and show them the way you want to. But you would need to develop it and install it on every PC that needs to use it.