Replace SonarCloud with SonarQube (#258)

Our CI pipeline uses SonarCloud for static code analysis using the `sonarsource/sonarcloud-github-action` action. This has recently been deprecated in favour of `sonarsource/sonarqube-scan-action` following the rebranding of SonarCloud to SonarQube Cloud. This PR therefore makes the required change to `ci.yml`.

We also resolve a code coverage issue by removing a previously-required fix; see DEFRA/water-abstraction-system#1557 for info.

.github/workflows/ci.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
         with:
-          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of sonarcloud analysis
+          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of SonarQube analysis
 
       # Before we do anything, check we haven't accidentally left any `experiment.only()` or `test.only(` statements in
       # the tests
@@ -72,19 +72,13 @@ jobs:
         run: |
           npm run migrate
 
-      # This includes an extra run step. The sonarcloud analysis will be run in a docker container with the current
-      # folder mounted as `/github/workspace`. The problem is when the lcov.info file is generated it will reference the
-      # code in the current folder. So to enable sonarcloud to matchup code coverage with the files we use sed to update
-      # the references in lcov.info
-      # https://community.sonarsource.com/t/code-coverage-doesnt-work-with-github-action/16747/6
       - name: Run unit tests
         run: |
           npm test
-          sed -i 's@'$GITHUB_WORKSPACE'@/github/workspace/@g' coverage/lcov.info
 
-      - name: Analyze with SonarCloud
+      - name: Analyze with SonarQube
         if: github.actor != 'dependabot[bot]'
-        uses: sonarsource/sonarcloud-github-action@master
+        uses: sonarsource/sonarqube-scan-action@master
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This is provided automatically by GitHub
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} # This needs to be set in your repo; settings -> secrets

.labrc.js

@@ -8,7 +8,7 @@ module.exports = {
   // Means when we use *.only() in our tests we just get the output for what we've flagged rather than all output but
   // greyed out to show it was skipped
   'silent-skips': true,
-  // lcov reporter required for SonarCloud
+  // lcov reporter required for SonarQube
   reporter: ['console', 'html', 'lcov'],
   output: ['stdout', 'coverage/coverage.html', 'coverage/lcov.info'],
   globals: ['globalThis'].join(',')

sonar-project.properties

@@ -3,32 +3,32 @@
 # Reference for how to glob files
 # https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/
 
-# Project key is required. You'll find it in the SonarCloud UI
+# Project key is required. You'll find it in the SonarQube (formerly SonarCloud) UI
 sonar.projectKey=DEFRA_hapi-pg-rest-api
 sonar.organization=defra
 
-# This is the name and version displayed in the SonarCloud UI.
+# This is the name and version displayed in the SonarQube UI.
 sonar.projectName=hapi-pg-rest-api
 
-# This will add the same links in the SonarCloud UI
+# This will add the same links in the SonarQube UI
 sonar.links.homepage=https://github.com/DEFRA/hapi-pg-rest-api
 sonar.links.ci=https://github.com/DEFRA/hapi-pg-rest-api/actions
 sonar.links.scm=https://github.com/DEFRA/hapi-pg-rest-api
 sonar.links.issue=https://github.com/DEFRA/hapi-pg-rest-api/issues
 
 # Path is relative to the sonar-project.properties file.
-# SonarCloud seems to have little intelligence when it comes to code coverage. Quite simply if it sees a code file, it
+# SonarQube seems to have little intelligence when it comes to code coverage. Quite simply if it sees a code file, it
 # checks it against our coverage report and if not found flags it as uncovered. This also effects the overall coverage
-# score. In our case this means SonarCloud could flag everything under test/ as lacking code coverage!
-# We have found this combinations of `sources`, `tests` and `tests.inclusions` means SonarCloud properly understands
-# what is code and what is a test file. Note the use of ./ in `sources`. This is the only way we found to include root
-# level files and ensure they are correctly resolved when SonarCloud scans the lcov coverage data.
+# score. In our case this means SonarQube could flag everything under test/ as lacking code coverage! We have found this
+# combinations of `sources`, `tests` and `tests.inclusions` means SonarQube properly understands what is code and what
+# is a test file. Note the use of ./ in `sources`. This is the only way we found to include root level files and ensure
+# they are correctly resolved when SonarQube scans the lcov coverage data.
 sonar.sources=src,./auto-pk-api.js,./config.js,./db.js,./index.js,./numeric-pk-api.js,./server.js,./sessions-api-context.js,./sessions-api.js
 sonar.tests=test
 sonar.test.inclusions=test/**/*.js
 
 # Encoding of the source code. Default is default system encoding
 sonar.sourceEncoding=UTF-8
 
-# Ensure SonarCloud knows where to pick up test coverage stats
+# Ensure SonarQube knows where to pick up test coverage stats
 sonar.javascript.lcov.reportPaths=coverage/lcov.info