SonarQube v8.9 LTS was just released and we hope you’ve already seen our announcement and are working on your upgrade!
A new SonarQube LTS represents a huge amount of work. Since the release of the previous SonarQube LTS (v7.9, in November 2019), there have been over 5200 development tickets merged in SonarQube and its underlying components. This includes new functionality, improvements to existing features, and bug fixes.
It’s a lot, and if we tried to talk about every change we’d be here a while. Since not everything can land in our big release announcements, I want to tell you about 7 cool features you might not know are included in the SonarQube v8.9 LTS.
Jenkins is an extremely popular CI tool for our users, but has always required tedious configuration for Branch Analysis / Pull Request Decoration even though the scanner could automatically detect the right values for other CIs.
You can finally kiss the manual configuration of
sonar.pullrequest.key goodbye (and remove them from your pipelines) now that SonarQube automatically detects the right values. It’s easier than ever to start analyzing code from your Jenkins pipeline.
Since SonarQube v6.6 (!), it has been hard coded into SonarQube that Quality Gate conditions on Coverage and Duplication should not be evaluated when less than 20 lines of code are in the New Code Period.
This was done because of our own experiences with "diminishing returns" situations where the cumulative change sets were small and one or two uncovered lines caused the project to fail the Quality Gate.
After receiving feedback from users and customers, we understood that there are teams and industries who need to be absolutely sure that even their smallest changesets meet these conditions. And so in the spirit of continuous improvement (and hearing your feedback!) this behaviour is now configurable! It can be adjusted at both the instance and project-level, with the default behaviour still being the permissive option.
You no longer have to worry about pre-provisioning a project before analysis if your main branch is named something other than master.
This helps users who choose to have projects provisioned automatically when a project key is used for the first time.
Whether you have a main branch named develop, or the first analysis of your project is a pull request, your project will get provisioned and analysis will succeed.
Programming languages are constantly evolving and new versions are regularly being released. SonarQube v8.9 LTS adds support for the latest versions of the programming languages you’re using, making sure analysis doesn’t fail on new language features and that rules stay relevant even in a new context.
|Language||SonarQube v7.9 (former LTS)||SonarQube v8.9 LTS|
* Rome wasn’t built in a day. :) SonarQube no longer fails to analyze C# 9 projects, but full support is still to come
It’s now possible to configure multiple instances of a DevOps platform to use for features like Pull Request Decoration. While previously only one of each supported platform could be configured, now the limit does not exist.
This is great for organizations who are migrating between on-prem and cloud versions of their DevOps platform, or who simply face a complex development-tool landscape internally.
This feature really makes sense for larger organizations, which is why it’s included in the Enterprise Edition of SonarQube and higher.
Speaking of DevOps platforms, now when you configure a new DevOps platform, you can be sure you’ve done the configuration correctly (used the right URL, set permissions correctly, etc.). This means a SonarQube administrator can guarantee the configuration is correct before users start trying to use it.
Once an analysis is completed scanner-side, it is sent to your SonarQube server to be processed. The sooner your analyses are processed by the Compute Engine, the sooner you get your project’s Quality Gate status and can find out if your code is squeaky clean (ready to be merged or released) or if it’s time to start fixing issues or improving your code coverage.
We’ll admit it -- as SonarQube itself has become more complex, so has the processing of analyses, and performance took a hit in SonarQube v7.9 LTS.
In SonarQube v8.9 LTS, we’ve made significant progress in improving the performance of the Compute Engine for all supported database platforms (using better caching and optimized queries), but we also made improvements specifically for SonarQube instances backed by an Oracle or Microsoft SQL Server database.
In SonarQube v8.9 LTS we addressed feedback that the way Code Coverage was presented in SonarQube’s UI wasn’t friendly to color-blind users. We’ve improved SonarQube’s coverage indicators by adding a space between the two colors, and using a darker red. This will benefit to users with Deuteranomaly thanks to a greater contrast:
- Improved the accessibility of coverage treemaps for color-blind users
- Ensured code coverage information is accessible for blind users using screen readers
Accessibility is important to us, and we have big plans this year to keep improving it in our products. You can join the discussion in our SonarSource Community topics about accessibility , and reach out there if we are missing something.
If you haven’t tried v8.9 LTS yet, I hope you now have 7 more reasons to prepare that upgrade with your team. This is a free version upgrade for all, and you can get the LTS in just a few clicks @ SonarQube Downloads . Need more help getting started? Check the following resources:
- SonarQube 8.9 LTS: 3 steps to a smooth upgrade
- Get help using the #8-9-lts-upgrade tag in the SonarSource Community
Something to add? Join us in the community!