Performing the update

Once you have determined your update path and tested your update, you can perform your SonarQube Server update.

Now that you have Determining the update path and performed the Pre-update steps, you can proceed with your update

Updating a ZIP file instance

Before you update, make sure you know how to Installation overview from the ZIP file and check that your environment Server host requirements of the version you’re updating to.

To update from the ZIP file:

1. Download and unzip the SonarQube Server distribution of your edition in a fresh directory, let’s say <newSonarqubeHome>.

2. If you’re using third-party plugins, manually install plugins that are compatible with your version of SonarQube Server. Use the Plugin version matrix to ensure that the versions you install are compatible with your server version. Simply copying plugins from the old server to the new is not recommended; incompatible or duplicate plugins could cause startup errors. Analysis of all languages provided by your edition is available by default without plugins.

3. Update the contents of sonar.properties file (in <newSonarqubeHome>/conf) with the settings in the <oldSonarqubeHome>/conf directory (web server URL, database, ldap settings, etc.). Do not copy-paste the old files. If you are using the Oracle DB, copy its JDBC driver into <newSonarqubeHome>/extensions/jdbc-driver/oracle.

4. Stop your old SonarQube Server.

5. Start your new SonarQube Server.

6. Browse to http://yourSonarQubeServerURL/setup and follow the setup instructions.

7. Reanalyze your projects for a better experience.

Updating a Docker image instance

To update SonarQube Server using the Docker image:

1. Stop and remove the existing SonarQube Server container:

$ docker stop <container_id>
$ docker rm <container_id>

2. Set up and start your container.

$> docker run -d --name sonarqube \
    -p 9000:9000 \
    -e SONAR_JDBC_URL=... \
    -e SONAR_JDBC_USERNAME=... \
    -e SONAR_JDBC_PASSWORD=... \
    -v sonarqube_data:/opt/sonarqube/data \
    -v sonarqube_extensions:/opt/sonarqube/extensions \
    -v sonarqube_logs:/opt/sonarqube/logs \
    <image_name>

where <image_name> depends on the update target:

• for SonarQube Community Build: sonarqube

• for SonarQube Server Editions: check the tags currently available on the DockerHub page.

3. Go to http://yourSonarQubeServerURL/setup and follow the setup instructions.

4. Reanalyze your projects for a better experience.

• If you’re updating with an Oracle database or you’re using plugins, you can reuse your extensions volume from the previous version to avoid moving plugins or drivers. Use the Plugin version matrix to ensure that your plugins are compatible with your version. Analysis of all languages provided by your edition is available by default without plugins.

• If updating from 8.9.x LTA to 9.9.x LTA (Release cycle model: Please note that the lts tag on Docker images is replaced with every new LTA release. If you want to avoid an automatic major update, we recommend using the corresponding 9.9-<edition> tag instead of relying on the lts-<edition> tag.

• Unless you intend to delete the database and start new when running your image, be careful not to use -v to docker-compose down and, be careful when running commands like docker system prune or docker volume prune; regardless if you use an external: true parameter, your database volumes will not persist beyond the initial startup and shutdown of SonarQube Server.

Updating a Helm chart instance

• We highly recommend to Setting up autoscaling during long-running updates.

• If you’re updating with an Oracle database or you’re using plugins, you can reuse your extensions Persistent Volume Claims from the previous version to avoid moving plugins or drivers. Use the Plugin version matrix to ensure that your plugins are compatible with your version. Analysis of all languages provided by your edition is available by default without plugins.

Please verify that any custom configurations or custom values.yaml files contain only parameters that are still compatible with the targeted chart, and adjust them if needed. Some default values assigned to parameters may have changed between versions of the chart,or other parameters could have been removed.

Standard procedure

1. Change the SonarQube Server version parameter on your values.yaml:

   • Developer and Enterprise Editions: image.tag

   • Data Center Edition: searchNodes.image.tag and applicationNodes.image.tag

2. Redeploy SonarQube Server with the same helm chart:

helm upgrade --install -f values.yaml -n <yourNamespace> <yourReleaseName> <pathToSonarqubeHelmChart>

3. If you’re updating a Data Center Edition: after SonarQube Server’s search pods are running and ready, only one application (app) replica will be running and ready. You can confirm that it’s because of the ongoing update by inspecting the logs of the pod for this text: The database must be manually upgraded. Please backup the database and browse /setup.

4. Go to http://yourSonarQubeServerURL/setup and follow the setup instructions.

5. Reanalyze your projects to get fresh data.

If updating from 8.9.x LTA to 9.9.x LTA

Update from 8.9.x LTA to 9.9.x LTA

To install SonarQube 9.9 LTA, use the sonarqube Helm chart. The sonarqube-lts Helm chart is no longer maintained and cannot be used to install the new LTS.

• For SonarQube 9.9 LTA Community, Developer, and Enterprise Editions, the Helm chart version to use is 8.x.x . See sonarqube ArtifactHub for more information.

• For SonarQube 9.9 LTA Data Center Edition, the Helm chart version to use is 7.x.x . See sonarqube-dce ArtifactHub for more information.

As SonarQube only requires to persist the database, the general update process will consist of uninstalling your instance before installing the new LTA.

If you are using an external database, you don’t have any persistent data inside kubernetes. Therefore, there is no action required.

Instead, if you rely on the embedded PostgreSQL chart (not recommended), uninstalling the chart will keep the PVC alive. The PVC can then be reused either:

• by specifying postgresql.existingClaim in the values.yaml file

• by not changing parameter values, but making sure you install the new chart in the same namespace (auto-generated name will be the same).

Related pages

• Release cycle model

• Determining the update path

• Pre-update steps

• Post-update steps