SonarSource is proud to announce the release of 8.1, which includes Quality Gate status in GitLab Merge Request comments for all GL editions . More details in the official announcement.
In addition, there are a few other things to be aware of:
- We’ve rolled Short-Lived and Long-Lived branches into a single concept, so on all branches you get all measures and a full Quality Gate check, not just your ‘on New Code’ conditions. Previously-short-lived branches will need to be analyzed again to show all measures, and it’s possible that Quality Gate status and measures “on New Code” might change. You’ll also want to review your project’s housekeeping; there are new options. (MMF-1786)
- As part of the branches changes, we’ve updated what’s recognized as a “new” issue: only isses that touch new lines will be marked new now. (SONAR-12627)
- You can now manage your notifications on an individual project from that project’s homepage. (SONAR-10037)
- The coverage donut chart on the project homepage is now more colorblind-friendly. (SONAR-11601)
- Elasticsearch has been upgraded to 6.8.4, fixing the problem that caused SonarQube startup to fail with Java 13. Note that Java 13 is still not officially supported. (SONAR-12685)
- Some deprecated APIs, web services and web service parameters have been removed, and the
api/measures/component response has been simplified.
You’ll find more details in the upgrade notes and full details in the release notes. Please open new threads for any questions you have about these or other features.
As usual, download is available at sonarqube.org.
The download link goes to a 404 page…
Welcome to the community, and thanks!
It’s fixed now.
For the curious, we had a change in the release process this time that as a side effect added the build number to the artifact name and I missed that in updating the downloads page.
One more addendum: Our release process changes also affected updating the documentation. What’s posted as ‘current’ is still for 8.0. We’ll get the new docs out bright and early tomorrow, though.
The 8.1 documentation is now available on docs.sonarqube.org.
i’m a bit confused about the Java requirements for Sonarqube 8.x
Sonarqube server needs Java 11 to run since 7.9 LTS.
The most recent versions of Sonarqube Scanner for Ant and
Sonarqube Scanner for Jenkins have:
[sonar:sonar] SonarScanner will require Java 11 to run starting in SonarQube 8.x
[WARNING] SonarScanner will require Java 11+ to run starting in SonarQube 8.x
in their logs, but the analysis runs also with Java 8 and https://docs.sonarqube.org/latest/requirements/requirements/ has
SonarQube scanners require version 8 or 11 of the JVM and the SonarQube server requires version 11. Versions beyond Java 11 are not officially supported.
So it seems the proposed requirement Java11 for analysis has been canceled recently.
How long will Java 8 be sufficient for analysis ?
8.x means “at some point in the 8.x series”. It has not happened yet
Sorry to hijack this release announcement but it seems I can’t open a new topic elsewhere.
I have a small concern about this part:
I use Ansible to automatically install or upgrade SonarQube to the next release, and for this to work I rely on predictable artifact names, which is not possible anymore. Even the API call
system/upgrades doesn’t help too much as the published version name doesn’t include the build number (‘version’: ‘8.1’ vs ‘downloadUrl’: ‘…sonarqube-184.108.40.206237.zip’) while local version does (‘sonar_version’: ‘220.127.116.11455’).
Is it possible for you to either have this version object includes the build number or not adding the build number or perhaps to provide a redirection from https//binaries.sonarsource.com/Distribution/sonarqube/sonarqube-8.1.zip to https//binaries.sonarsource.com/Distribution/sonarqube/sonarqube-18.104.22.168237.zip to keep a consistent behavior with previous releases ?
Good to know
this provides clarity at last, had a lot of questions from developers because of this - misleading - log entries. Myself firmly believed we need to use Java11 for analysis with Sonarqube 8.x
Only after updating the staging instance to 8.1, i read the documentation and thought i’ve found
a bug in it. Then i tried analysis with Java 8 … and it worked
This should be more clearly defined in documentation and log entries.
Hi there, quick question:
In https://update.sonarsource.org/plugins/compatibility-matrix.html there are basically all Auth plugins marked incompatible after 7.9 LTS, also the “internal” ones, including the LDAP one which I am especially concerned about, since that’s what we are currently using in 7.9.1
Given I am asked to update that system to SonarQube 8.1 - what does incompatible mean? And what’s the proposed workaround and the longer term mitigation path?
Checkout the Upgrade Notes
Release 8.0 Upgrade Notes
GitHub, LDAP, and SAML authentication now built in
GitHub, LDAP, and SAML authentication is now built in. If you were using the authentication plugins (sonar-ldap, sonar-auth-github, and sonar-auth-saml), you need to remove them from SonarQube before upgrading. (SONAR-12471).