Breaking change on sonarqube-scan-action v3?

SonarQube
, ,
1

Hello,

This might be linked with other posts I’ve seen on the forum (eg. this one or this other one), but just in case.

Our renovate instance picked up last week an update for the Github Actions sonarqube-scan-action from v2 to v3.

We’re using the action as below:

runs:
  using: composite
  steps:
<REDACTED>
    - name: SonarQube Scan
      uses: sonarsource/sonarqube-scan-action@v2
      with:
        args: >
          -Dsonar.projectKey=${{ inputs.sonar_project }}
      env:
        SONAR_TOKEN: ${{ inputs.sonar_token }}
        SONAR_HOST_URL: ${{ inputs.sonar_host_url }}
<REDACTED>

The action was running successfully so far, but after switching to v3, we ended up with the following error:

Run sonarsource/sonarqube-scan-action@v3
/usr/bin/docker run --name <REDACTED> --label <REDACTED> --workdir /github/workspace --rm -e "SONAR_TOKEN" -e "SONAR_HOST_URL" <REDACTED> --entrypoint "/entrypoint.sh" -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" end":"/github/workspace" <REDACTED> -Dsonar.projectKey=<REDACTED>
09:10:11.906 INFO  Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
09:10:11.909 INFO  Project root configuration file: NONE
09:10:11.921 INFO  SonarScanner CLI 6.1.0.4477
09:10:11.922 INFO  Java 17.0.11 Eclipse Adoptium (64-bit)
09:10:11.922 INFO  Linux 6.5.0-1025-azure amd64
09:10:11.944 INFO  User cache: /opt/sonar-scanner/.sonar/cache
09:10:12.871 INFO  EXECUTION FAILURE
09:10:12.872 INFO  Total time: 0.968s
09:10:12.872 ERROR Error during SonarScanner CLI execution
java.lang.IllegalStateException: Failed to get server version
	at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.getServerVersion(ScannerEngineBootstrapper.java:148)
	at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:112)
	at org.sonarsource.scanner.cli.Main.analyze(Main.java:75)
	at org.sonarsource.scanner.cli.Main.main(Main.java:63)
Caused by: java.lang.IllegalStateException: Error status returned by url [***api/v2/analysis/version]: 404
	at org.sonarsource.scanner.lib.internal.http.ServerConnection.callUrl(ServerConnection.java:182)
	at org.sonarsource.scanner.lib.internal.http.ServerConnection.callApi(ServerConnection.java:145)
	at org.sonarsource.scanner.lib.internal.http.ServerConnection.callRestApi(ServerConnection.java:123)
	at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.getServerVersion(ScannerEngineBootstrapper.java:143)
	... 3 common frames omitted
09:10:12.873 ERROR 
09:10:12.873 ERROR Re-run SonarScanner CLI using the -X switch to enable full debug logging.

Note that switching back to v2 reverts to a successful run.
Our sonarqube instance is public and behind HTTPS.

Has there is no release notes or README for v3 so far, should we consider v3 experimental until further notice ? Is there a change I might have missed in the documentation ?

Thanks in advance for your help.

2

Hi,

Welcome to the community!

What’s your version of SonarQube?

 
Thx,
Ann

3

Hi,
Server is v10.6 (92116)
Github actions is 2.3.0

1 Like
4

Hi,

Thanks for those details. Can you access the ***api/v2/analysis/version URL?

 
Thx,
Ann

5

Hi!
Yes, the URL is accessible (although only authenticated through Google SSO - in incognito mode, it will redirect me to the Google authentication page)& here is the response:

10.6.0.92116
6

Hi,

Ehm… How is the build agent supposed to SSO?

 
Ann

7

Sorry, I should have been clearer,
User-based connections are made via SSO
Github Actions authenticates via token

8

Hi,

Thanks for clarifying. I’m going to flag this for more expert eyes.

 
Ann

1 Like
11

Hi @benbouillet

We are currently investigating a regression regarding SSL configuration. You said your SonarQube server is exposed through SSL. Are you using a self-signed certificate? If yes, how are you configuring it in the GitHub action?

However, this is very strange that you received a 404 for the call to api/v2/analysis/version. For an SSL issue, I would expect a stacktrace with SSLPeerUnverified error or something like that. Is your SSL reverse proxy expecting SSL client authentication maybe?

12

Hello,

We’re using Let’s Encrypt certificates.
The reverse proxy is not using authentication, also we are filtering the public routes, opening only:

  • /batch/index
  • /batch/file
  • /api/plugins/download
  • /api/plugins/installed
  • /api/settings/values
  • /api/qualityprofiles/
  • /api/ce/submit
  • /api/languages/list
  • /api/metrics
  • /api/rules/
  • /api/project_badges/measure

Is api/v2/analysis/version a new route used only starting v3 ?

13

Yes, and there will be other new endpoints used by the scanner, to provision the JRE.

In general, we want to keep the freedom to add new endpoint calls to the analysis process, so I am not sure if whitelisting them one-by-one is going to scale.

14

Thank you for your answer,
I can confirm that whitelisting the endpoint solved the issue.
So this is on our side, sorry for the inconvenience.
However, whitelisting specific routes is a common pattern, and we cannot circumvent this limit ; could you at least specify the newly accessed routes in the changelog when releasing a new version please ?

15

The analysis engine is dynamically bootstrapped from the server, so the scanner behavior may also change when you update the SonarQube server to a new version, without a new release of the GitHub action.

16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.