List of Figures
Chapter 1. An introduction to SonarQube
Figure 1.1. Trending is a core feature of SonarQube, with changes represented in a variety of formats, including this spark
line-style graph that can be added to any dashboard.
Figure 1.2. SonarQube’s front page is the default filter, which lists a few choice metrics about each project under analysis.
Figure 1.3. SonarQube’s default dashboard
Figure 1.4. The size metrics widget shows how many lines of code, methods, classes, and packages were found during analysis.
Figure 1.5. The events widget gives a quick list of events recorded for the project.
Figure 1.6. The description widget shows basic data about your project and its last analysis.
Figure 1.7. The issues widget combines potential bugs and coding rules under the issues banner.
Figure 1.8. The test coverage widget reports on how well your code base is covered by unit tests, and how those tests are
doing.
Figure 1.9. The comments and duplications widget covers two quality axes, showing both how well your public methods are documented
(high scores are good) and how many duplications you need to eliminate (high scores are bad).
Figure 1.10. The package design widget shows how clean your design implementation is, giving you high-level figures showing
how much work needs to be done to make the implementation as clean as the original design undoubtedly was.
Figure 1.11. The LCOM4 and response for class widgets show how your code stacks up from an object-oriented design perspective.
Ideally, both graphs would be weighted to the left, meaning that the classes in your program are small and simple.
Figure 1.12. The complexity widget shows the distribution in your program of high-complexity methods or classes. The more
complex a program is, the more difficult it becomes to maintain; so, ideally, this graph will be weighted to the left.
Figure 1.13. Drilldowns in SonarQube start with the chosen metric and its value in the top row. That’s followed by a row of
hierarchical widgets: modules (if any—there aren’t any here) in the left-most box, then directories/packages, then classes/files.
Each widget’s contents are sorted by its metric value. Click any module or package to filter widgets to its right.
Figure 1.14. The file details view offers a consolidated spot to see most of the metrics SonarQube’s gathered on a particular
file. The Source tab shows the file’s full contents.
Figure 1.15. Trend arrows are used throughout the SonarQube interface to indicate the 30-day trend of a metric. Red, green,
and grey arrows indicate bad, good, and neutral changes. Arrows alone show moderate increases. An arrow with a line shows
a strong increase.
Figure 1.16. Technical debt is designed to communicate the full liability of unaddressed issues in your code base clearly—what
they could potentially cost you, and where they’re coming from.
Chapter 2. Issues and coding standards
Figure 2.1. The issues widget gives the total number of issues, the breakdown of that count by level of severity, and the
Rules Compliance Index.
Figure 2.2. The Rules Compliance Index is the Weighted Issues score (your counts of issues multiplied by severity factors),
divided by the number of lines of code in the project, turned into a percentage, and subtracted from 100.
Figure 2.3. The four widgets you first see in the issues drilldown represent a hierarchy: severity, rules, packages, and classes/files.
Each widget after Severity is sorted by the number of hits against the items listed. Click at any level to filter the widgets
lower in the hierarchy. Click a file or class name to begin seeing issues in that file at any time.
Figure 2.4. Once you click a file, you’re shown the issues in that file with a few lines of context on each side. If you have
the SCM Activity plugin in place, you see not only the problem code and its line number, but also who checked it in and when.
Figure 2.5. SonarQube’s issue severities match up only loosely with the categories we’ll use in this chapter to discuss the
kinds of issues that are flagged.
Figure 2.6. Null pointer dereferences fall into the bugs category.
Figure 2.7. If everything works well, on line 1096 this method will close the FileOutputStream that was created on line 1084.
But if an exception is encountered in the middle, that resource leaks instead. If this happens once or twice, you may never
notice. Let it go on long enough, though, and you’ll bring your application to its knees.
Figure 2.8. An empty conditional may mean the coder forgot to do something.
Figure 2.9. Conditionals without curly braces could lead to future programmer error.
Figure 2.10. Strings are easy to abuse in Java, and SonarQube offers several rules to ensure that you’re using them efficiently.
Figure 2.11. Any user can see the rule profiles by using the Configuration link at upper right of the screen.
Figure 2.12. Administrators have the ability to create and edit rule profiles and change which profile is the language’s default.
Figure 2.13. Projects can be assigned to a non-default profile for analysis.
Figure 2.14. The SCM Activity plugin adds committer and commit-date information to the file detail view. This screenshot shows
a section of code, starting at line 54 of the file, that was checked in on 7/26/2012.
Chapter 3. Ensuring that your code is doing things right
Figure 3.1. SonarQube’s testing widget on the default dashboard
Figure 3.2. Unit-test metrics
Figure 3.3. Unit-test coverage metrics
Figure 3.4. Drilldown view of code coverage
Figure 3.5. Drilldown view of line and branch coverage
Figure 3.6. The Coverage tab of a source code file
Figure 3.7. Coverage tab view selection
Figure 3.8. Source code viewer with coverage indicators
Figure 3.9. SonarQube’s testing widget on the default dashboard
Figure 3.10. List of test methods in a test file
Figure 3.11. The Expand link reveals the root cause of a test error.
Figure 3.12. Integration-test widget
Figure 3.13. Source code Coverage tab with IT metrics
Figure 3.14. Coverage tab view selection—enriched with IT choices
Figure 3.15. Thucydides plugin widget
Figure 3.16. Thucydides acceptance-test metrics mapped to unit-test metrics
Chapter 4. Working with duplicate code
Figure 4.1. SonarQube detects duplications in files and projects and also across projects.
Figure 4.2. Duplications widget information
Figure 4.3. Drilldown view example: density of duplicated lines
Figure 4.4. The Duplications tab view of a file/class
Figure 4.5. The Duplications tab’s file header
Figure 4.6. Locate the exact position of duplicated code in two classes.
Figure 4.7. Viewing all lines containing detected code repetition
Figure 4.8. Enabling cross-project duplication detection
Figure 4.9. Cross-project duplication in source code tab
Figure 4.10. Useless Code Tracker plugin
Chapter 5. Optimizing source code documentation
Figure 5.1. The comments and duplications widget appears in SonarQube’s default dashboard.
Figure 5.2. SonarQube metrics shown in the comments and documentation widget
Figure 5.3. When the click-through metric is Public Undocumented API, the drilldown view is a variation on the norm. Instead
of seeing files sorted by that density, they’re shown with and sorted by the absolute number of undocumented API.
Figure 5.4. Source code tab’s header
Figure 5.5. Simple documentation process
Figure 5.6. Visual comparison between SonarQube’s original widget and the cloned widget provided by the Widget Lab plugin
Figure 5.7. Doxygen plugin’s new link and new Documentation tab in the source code viewer
Chapter 6. Keeping your source code files elegant
Figure 6.1. Dashboard complexity widget
Figure 6.2. Files distribution/complexity bar chart
Figure 6.3. Complexity metrics shown in source code viewer default tab
Figure 6.4. LCOM4 and RFC metrics shown in dashboard widgets
Figure 6.5. SonarQube reports on LCOM4 with a separate tab in the file source code viewer. The beauty of the LCOM4 tab is
that you get a visual representation of which methods (an m in a reddish circle) are connected to which fields (an f in a
yellow circle), and how the relations are formed.
Figure 6.6. Connected methods and attributes of the AmericanBreakfast class
Figure 6.7. By tying together the separate components, you make the class comply with the Single Responsibility Principle.
It has only one task: to prepare an American breakfast.
Figure 6.8. The RFC widget is one of the simplest, with only a distribution graph and an average score.
Figure 6.9. Various design metrics in the source code viewer tab
Figure 6.10. Afferent/efferent couplings of a class in the source code viewer
Chapter 7. Improving your application design
Figure 7.1. SonarQube dashboard widget pertaining to cycles and dependencies
Figure 7.2. Package-dependency graph, demonstrating a package cycle
Figure 7.3. Drilldown view for design metrics
Figure 7.4. DSM view for library and package dependencies
Figure 7.5. Column headers would make the DSM look busy.
Figure 7.6. Colored cells in the DSM report on dependencies and cycles between components.
Figure 7.7. Viewing dependencies of selected component in the DSM
Figure 7.8. Clicking a DSM cell. Dependencies between selected components are highlighted and differently colored in both
directions. The clicked cell also turns purple.
Figure 7.9. DSM sorting. High-level components appear at the top of the list.
Figure 7.10. Unwanted cycles are displayed in the upper-right triangle.
Figure 7.11. Double-click a numbered cell, and you see a list of outgoing file dependencies between the selected packages.
Clicking a file name pops up a window with the file detail view you’ve seen before.
Figure 7.12. Double-clicking a row drills down the DSM to the next navigation level.
Figure 7.13. Library-dependency tree for Java Maven projects
Figure 7.14. Dynamic library filtering
Figure 7.15. You can reach the dependencies view via two entry points in SonarQube.
Figure 7.16. Finding library dependencies
Figure 7.17. Typical layered architecture of a Java EE application
Chapter 8. Planning a strategy and expanding your insight
Figure 8.1. The rules compliance widget appears on the default dashboard, making the RCI a prominent gut-check metric. It
also shows the count of issues at each level of severity.
Figure 8.2. This version of the issues widget includes all the metrics in the standard rules compliance widget, and it also
shows the project’s WI score. (Issues used to be called violations.)
Figure 8.3. The hotspot metrics widget provides an easy reference for which files or classes have the highest score for any
given metric. You can have as many instances of the widget as you like, each configured to a different metric.
Figure 8.4. The Time Machine dashboard is composed of multiple instances of the history table widget, each configured for
a different quality axis, and the timeline widget, at upper left, which gives a granular history of up to three metrics.
Figure 8.5. The timeline widget, at the dashboard’s upper left, offers a colorful, granular graph of your project’s history.
There’s no fixed y-axis, though, so mouse over the graph to have the relevant values shown in the legend.
Figure 8.6. Don’t let your intuition rule too strongly when you’re reading the timeline widget’s graphs. Because each line
in the graph is essentially an independent sparkline, you need to mouse over the graph to see the numeric values whenever
they show what looks like a large jump. As the bottom two figures show, a line can jump the full height of the graph for a
change of less than 1: .7 in this case. The upper two figures show the opposite end of the spectrum, with a full-height jump
for a change of 196.
Figure 8.7. The history table widget shows sparklines and historical values of up to 10 metrics. By default, it shows the
first value on record, the last value on record, and the value from the last time the project’s version number changed. The
sparklines to the right reflect only those values shown in the widget, not the kind of detailed graphing that’s available
from the timeline widget shown in figure 8.6.
Figure 8.8. Each event in a project’s history is marked by a blue triangle on the X axis. Mouse over the triangle to add its
name to the graph.
Figure 8.9. The treemap defaults to a subblock for each project, with relative block size indicating Lines of Code, and block
color (cool, grassy green to angry red) indicating rules compliance. Click in the unlabeled part of the block to drill in
to a treemap of that block’s components. Click-through on the block’s name to land at a dashboard for that component.
Figure 8.10. The Components view shows a filter-style listing of the modules or packages in your project.
Figure 8.11. The breadcrumb trail that’s added at upper left in the interface shows how deeply you’ve drilled in to the Components
view.
Figure 8.12. As with the drilled-in version of the Components view, the default dashboard looks almost the same from level
to level. This version of the dashboard reflects a few of the suggestions we’ve been making, including the use of the Widget
Lab plugin’s WI rules compliance widget in place of the standard rules compliance widget at upper right, and the addition
of a treemap widget.
Figure 8.13. The Tab Metrics plugin adds a tab to the file detail view that lists every metric available for the file.
Figure 8.14. You can use Widget Lab’s WI rules compliance widget to put WI front and center on your project dashboards.
Chapter 9. Continuous Inspection with SonarQube
Figure 9.1. Source code management with a CI server that pulls source code changes and triggers builds
Figure 9.2. Source code management with CI server and SonarQube. Build automatically triggers SonarQube analysis.
Figure 9.3. Not paying down technical debt will make your system hard to maintain and will eventually decrease productivity.
Figure 9.4. Installing SonarQube plugin through Jenkins’ update center
Figure 9.5. When the plugin is downloaded, you’re notified.
Figure 9.6. Adding a new SonarQube installation in Jenkins
Figure 9.7. The SonarQube plugin’s available configuration options
Figure 9.8. SonarQube plugin: available triggering configuration options
Figure 9.9. Setting up a SonarQube Runner installation is easy. Click the Add button, name the installation, and choose Install
Automatically.
Figure 9.10. SonarQube analysis is available as either a build step or a post-build action, but the only time you want to
use the post-build option is for Maven projects.
Figure 9.11. Configuring standalone SonarQube Runner properties
Figure 9.12. Advanced configuration for a SonarQube post-build action
Figure 9.13. The Differential drop-down menu in the project’s dashboard
Figure 9.14. Picking an option from the Differential drop-down list changes the widgets.
Figure 9.15. Colored numbers indicate improvement, deterioration, or no impact on quality analysis.
Figure 9.16. Unit-testing widget when a differential view is enabled
Figure 9.17. The rules compliance (issues) widget when a differential view is enabled
Figure 9.18. Issues widget when a differential view is enabled
Figure 9.19. The Issues tab in the source code viewer shows only new issues when a differential view is selected.
Figure 9.20. The Compare tool lets you compare selected metrics from multiple versions—of the same project or different ones!
Figure 9.21. CI log output when analyzing SonarQube with the Build Breaker plugin enabled
Chapter 10. Letting SonarQube drive code reviews
Figure 10.1. Arriving at the issues drilldown from the left-hand menu (not visible here) shows you all issues in all classes
and all packages.
Figure 10.2. SonarQube does more than show you what the problem is. If you’re logged in, it also gives you links to workflow
functions at the bottom of each issue block that let you actively manage the problem.
Figure 10.3. Clicking the title of an issue adds more detail in line. Sometimes the information it offers is helpful. Other
times it’s just a longer version of the issue title.
Figure 10.4. You can make as many comments as you like on an issue. They’re shown in a running log.
Figure 10.5. The assignment form lets you assign the cleanup of an issue to any user SonarQube recognizes or auto-assign it
to yourself.
Figure 10.6. SonarQube sometimes flags code that complies with the rules.
Figure 10.7. Once an issue is flagged as a false positive, SonarQube won’t re-report that issue as long as the flagged line
hasn’t changed.
Figure 10.8. Look for the Change Severity option under More Actions. The dialog that’s added presents a severity drop-down
and a comment input. Once you submit the form, SonarQube confirms your severity change by immediately showing the new severity
in the issue block.
Figure 10.9. Tucked under the issue age, so it doesn’t clutter the interface by default, is the issue’s audit trail. Here
you can see what actions have been performed on an issue, when, and by whom.
Figure 10.10. Manual rules consist of a name, and a description, which is used in the pop-up you get when you click the rule
title in an issue block.
Figure 10.11. To get started with a manual issue, click the plus sign that seems to follow your mouse in the left column of
views that show code.
Figure 10.12. The manual issue form lets you choose the rule to use and requires you to fill in a comment. Once entered, manual
issues looks just like their “automatic” siblings.
Figure 10.13. The status-transition diagram for most issues
Figure 10.14. Manual issues are never closed because there’s no rules engine that can “rule” on them.
Figure 10.15. The unresolved issues by status widget gives an overview of all active issues.
Figure 10.16. The my unresolved issues widget shows issue severity, title, last modified date, and most recent comment on
the first five issues assigned to the logged-in user.
Figure 10.17. Clicking the title of an issue displays an issue summary presentation very like what you see in the issues drilldown.
It doesn’t pop up in a new window, but rather as an overlay in the current page. You can close it using either the Escape
key or the close button at lower-right on the screen.
Figure 10.18. The taglist widget tracks //NOSONAR and //TODO comments, offering click-throughs to the files involved.
Figure 10.19. The taglist widget’s underlying mechanism is a pair of issues, so you can either search the Source view for
the relevant comment or flip over to the Issues view and use the drop-down menu to see the flagged comments.
Figure 10.20. The manual severity widget shows both current and original severities.
Figure 10.21. The management interface for action plans presents a list of existing action plans on the left and an action-plan
creation form on the right.
Figure 10.22. When you link issues to an action plan, a colored progress bar is added to the interface. The progress bar and
accompanying issue totals are linked to lists of the relevant issues.
Figure 10.23. Once your action plans are created, you can assign issues from the More Actions menu in the issues block. Choose
the plan to use, and optionally add a comment.
Figure 10.24. The open action plans widget gives you an at-a-glance status of all your open action plans, with links to lists
of the relevant issues.
Figure 10.25. The JIRA widget shows your project’s issue counts, both in aggregate and by priority.
Figure 10.26. Once you’ve installed and configured the JIRA plugin, look under More Actions to find the option to add a JIRA
ticket from SonarQube. When you submit, you’ll see a link to the ticket in the issue comment.
Figure 10.27. You can have as many copies of the “Comment pattern matcher” rule as you like. The taglist widget displays them
all.
Figure 10.28. The pie in the taglist widget has a section for each relevant rule you’ve activated: one for the NOSONAR rule,
and one for each instance of the Comment pattern matcher rule.
Chapter 11. IDE integration
Figure 11.1. The description widget provides some of the static vitals of a project, including which profile it’s analyzed
with.
Figure 11.2. Each profile makes its lists of rules available as XML documents: one for each rules engine and one for the profile
as a whole.
Figure 11.3. The SonarQube plugin for Eclipse helps you close the circle of code quality. It gives you local visibility into
existing issues in the files you’re working on, helps you manage your issue assignments, and lets you prescan your code changes
for issues.
Figure 11.4. Eclipse plugin installation starts with the URL of a download site. From there, Eclipse takes over, checking
dependencies, retrieving all the pieces, and getting your agreement to the appropriate licenses.
Figure 11.5. At minimum, you need to tell Eclipse where your SonarQube server is. If you want to be able to manage your assigned
issues from within Eclipse, you also need to set up the credentials you use to log in to SonarQube. If your SonarQube authentication
is integrated with LDAP, don’t forget that you’ll need to come back here after a password change!
Figure 11.6. To associate your project with SonarQube, type the project name in the Sonar Project field, if it’s not prefilled
for you.
Figure 11.7. SonarQube linking adds several markers to the Eclipse interface, including one on the project and a marginal
marker for each existing issue synched in from the server. Existing issues also show up as warnings in the Problems view.
Figure 11.8. Use the Synchronize button to re-synchronize SonarQube issues.
Figure 11.9. You can easily reconfigure the search that underlies the Sonar Issues tab to show only issues assigned to you.
In fact, you can configure and save as many searches as you’d like. Once they’re saved, you’ll access them from the Show option
in the view menu.
Figure 11.10. If everything’s working as it should, you see a virtuous cycle of improved code quality and higher developer
productivity from the combination of Continuous Inspection, code reviews, and Eclipse integration.
Figure 11.11. The output from the Issues Report analysis is a single HTML file that shows at a project-level and file-by-file
level which rules were violated and how many of the issues are new since the last full analysis.
Chapter 12. Security: users, groups, and roles
Figure 12.1. The Users interface gives a list of current users, links to manage each one, and the form to create new users.
Figure 12.2. When you click the link to edit a user, the Edit User form replaces the Add New User form. This is typically
a blink-and-you’ll-miss-it operation.
Figure 12.3. Once you’ve deleted a user, you can get him back by re-adding a user with the same login. If resurrection wasn’t
intended, the additional confirmation shown here gives you the chance to go back and try another user name.
Figure 12.4. Users can perform their own password changes and set their email preferences, as well as manage their own filters.
Figure 12.5. Users can make their own private dashboards with whatever filters and widgets they like. New dashboards appear
in the left navigation rail just like any other dashboard. Users can control the order in which dashboards appear.
Figure 12.6. With fewer options, the group-management interface is even more straightforward than the one for users.
Figure 12.7. The group membership interface presents two lists: the in crowd on the right and everyone else on the left. Use
the arrows between the two lists to move people from one side to the other.
Figure 12.8. The Roles interface is where projects, users, and groups all come together, giving you a dashboard of who has
what permissions on any given project.
Figure 12.9. To add a group to a project role, highlight it on the left, use the Select button to move it to the right, and
save your changes.
Figure 12.10. Project administrators have an additional menu of options—options that allow them to tweak every setting on
a project.
Figure 12.11. A project’s users are the ones who are able to see it.
Figure 12.12. The User role grants access to view every facet of a project but one: seeing the code. That’s what the Code
Viewer role does.
Figure 12.13. The System Administrators interface is the simplest of the security screens, with links to edit the lists of
users and groups who have the privilege to make system-level changes.
Chapter 13. Rule profile administration
Figure 13.1. Clicking the Configuration link at the top of the page takes you to a list of rule profiles. Logged-in administrators
can easily copy any profile with the click of a mouse. The only hard part is coming up with a good name for the new profile.
Figure 13.2. You create a profile from scratch via a form that’s added inline on the page. Depending on the language, you
may get the opportunity to seed your new profile with rules from some of the language’s available rules engines, uploaded
in an engine-specific format.
Figure 13.3. The rules that make up a profile are presented in a search/search result interface. The default presentation
is all rules in the profile.
Figure 13.4. Use the drop-down menu to the left of any rule to adjust its severity in that profile. Note that no other profile
is affected by this change.
Figure 13.5. The rule search interface is straightforward. You can search by any combination of rule name, rule engine, severity,
and status. It defaults to showing all active rules in the current profile.
Figure 13.6. Each selection in the rule search accepts multiple options. Directly under the search form, a Bulk Change drop-down
menu lets you activate or deactivate every rule on the page at once.
Figure 13.7. The Profile Inheritance tab lets you set a parent profile. It also reports on a profile’s lineage, including
the number of rules the current profile inherits.
Figure 13.8. Inherited rules appear in a profile’s rule search. You can’t deactivate them, but you can change their severity.
If you do change an inherited rule’s severity, its inheritance icon changes to one that’s partially red.
Figure 13.9. The Profile Inheritance tab reports not only on the inheritance relationship, but also on the state of it, showing
the total number of overridden rules.
Figure 13.10. The rule details for an inherited rule contain a summary of that rule’s inheritance status in the current profile.
If you’ve overridden some aspect of the rule, such as severity, you can realign the rule with the parent profile using the
Revert to Parent Definition button, which only appears conditionally.
Figure 13.11. Rules that cite specific numbers are often configurable, but they’re not the only configurable rules.
Figure 13.12. The variety of possible rule configurations is as wide as the rules they configure, from simple integers and
Booleans to regular expressions, method names, and package names.
Figure 13.13. Copying a rule is a straightforward process, from the Copy Rule link to filling in the rule details (including
the description that will be used in the rule’s pop-up). After you’ve created the rule, you land back at a search result for
it so you can enable it in your profile.
Figure 13.14. The process of creating new rules by copying is a forgiving one. Want to change the default severity? Use the
Edit Rule link. Ditto the name and the description. If you decide you didn’t need the rule after all, you can always delete
it.
Figure 13.15. Extend the description of a rule in one profile, and you’ve extended it for all profiles. You can use limited
markdown syntax to help get your point across.
Figure 13.16. Rule notes are profile-specific reminders you can set on any rule. They appear when you expand the rule details
in the profile administration interface, and nowhere else.
Figure 13.17. You can set as many alerts as you’d like. They’re simple Boolean tests against metric thresholds.
Figure 13.18. SonarQube gets more colorful once you’ve set up alerts. The alert widget, shown three times on the left, uses
a stoplight scheme to convey alert status. Any other widget that displays an alerted metric will also use color if the value
has crossed an alert threshold, as shown with duplications on the right.
Figure 13.19. Each change you make to a rule set is recorded granularly.
Figure 13.20. Setting or revoking an inheritance relationship between profiles isn’t explicitly recorded in a changelog, but
you can nonetheless find clues to a relationship. For instance, the addition or deletion of a couple hundred rules in the
space of a minute is a strong indicator. An irrefutable one is the presence of multiple changes in a single record, because
SonarQube doesn’t record changes made manually in that way.
Figure 13.21. The description widget and the events widget both reflect profile version changes.
Figure 13.22. You access the profile comparison interface from the Compare Profiles link at the top of the list of profiles.
It lets you compare any two profiles, regardless of language, and shows the differences in summary form at the top with a
list of details at the bottom.
Figure 13.23. Use the interface on the Projects tab to assign projects to a specific profile for analysis. This works even
on the uneditable profiles.
Figure 13.24. The Restore Profile link at the top of the Quality Profiles page adds a form that allows you to restore a backup.
Just make sure you aren’t trying to restore over an existing profile; you need to delete the current copy first.
Figure 13.25. Whereas the standard alerts widget (left) presents all alerts in paragraph form, the project alerts widget (right)
breaks out each alerting metric for a clearer picture of what’s past its error threshold and what’s at warning stage. The
bar graphs to the right show you how far out of compliance the metric is.
Chapter 14. Making SonarQube fit your needs
Figure 14.1. Managing filters and performing a search
Figure 14.2. SonarQube’s flexible search form
Figure 14.3. Filter administration page
Figure 14.4. Change Columns panel at the top of the search results
Figure 14.5. Previewing and customizing how a filter looks as a treemap
Figure 14.6. Creating a differential filter
Figure 14.7. Results preview of a differential filter
Figure 14.8. Adding a file to your favorites
Figure 14.9. The Manage Dashboards link is available on your home page.
Figure 14.10. Global dashboard configuration page
Figure 14.11. Every new global dashboard is added to the My Global Dashboards list.
Figure 14.12. Global dashboard customization page
Figure 14.13. Adding the global widget Measure Filter as List to a global dashboard
Figure 14.14. Adding a project widget to a global dashboard requires that you specify the project from which SonarQube will
fetch widget data.
Figure 14.15. Project widgets in global dashboards have a header you can drag and drop between columns, and a title displaying
the project or filter name.
Figure 14.16. A complete global dashboard. The left column contains one global filter widget, and the right column contains
three instances of the same project-coverage widget showing information for different projects.
Figure 14.17. Default dashboard administration
Figure 14.18. Email settings: activation of SonarQube notifications
Figure 14.19. Event subscription
Figure 14.20. The Rules Compliance Index is the Weighted Issues score divided by the number of lines of code in the project,
turned into a percentage and subtracted from 100.
Figure 14.21. Configuration backup and restore, made easy by SonarQube
Figure 14.22. SonarQube’s update center
Figure 14.23. Installing a SonarQube plugin from the update center
Chapter 15. Managing your projects
Figure 15.1. SonarQube ships with five default project dashboards. They’re available in the upper-left menu when you’re viewing
a project.
Figure 15.2. Adding a widget in a project dashboard is simple because you don’t need to specify the project, as you probably
expect from chapter 14.
Figure 15.3. Assigning project quality profiles for supported languages
Figure 15.4. SonarQube ships with three manual metrics. The administration page is simple: it lists all available metrics
and provides a form to add new or edit existing ones.
Figure 15.5. The Edit and Delete links are shown only in custom manual metrics.
Figure 15.6. Manual measures (empty) administration page
Figure 15.7. Adding a new manual measure
Figure 15.8. A golden marker points out which measures have not yet been integrated with the rest of the SonarQube metrics.
Running a new project analysis removes these markers.
Figure 15.9. Displaying custom measures in a dashboard takes two steps: add the custom measures widget, and select the measures
you want to show.
Figure 15.10. By modifying exclusions settings, you can make SonarQube exclude source files based on patterns.
Figure 15.11. Every detail of your project’s history on one page
Figure 15.12. Moving your mouse over a row displays various actions depending on the row’s content. You can create a new version,
add multiple custom events, rename them, or remove them from the selected snapshot.
Figure 15.13. Project Roles page, which is similar to the global roles administration page
Figure 15.14. You can define up 10 ten links for every project, but only half of them can be generic and managed though SonarQube’s
UI.
Figure 15.15. SonarQube lets you edit a project’s key, but you should do this before triggering a new analysis of the project
with the new key.
Figure 15.16. You can delete several projects at the same time by using the Bulk Deletion feature.
Figure 15.17. Checking the Select
Chapter 16. Writing your own plugin
Figure 16.1. SonarQube’s internal architecture
Figure 16.2. Project structure and contents of the plugin created by the SonarQube Maven archetype
Figure 16.3. SSLR-based language plugin (JavaScript) project structure
Appendix A. Installation and setup
Figure A.1. Congratulations! SonarQube is up and running.
Appendix B. Analysis
Figure B.1. Editing settings.xml with NetBeans and Eclipse IDE
