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.
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.
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
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 ?
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-8.1.0.31237.zipâ) while local version does (âsonar_versionâ: â8.0.0.29455â).
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-8.1.0.31237.zip to keep a consistent behavior with previous releases ?
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.
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?
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).