SonarCloud analysis returns 403 (GitHub workflow was previously working)

SonarQube Cloud
1

For my workflow, sonarqube-scan-action@v4 suddenly stopped working. The same GitHub workflow definitions and the very same configuration (repository secrets etc.) still worked a short time ago.

  • ALM used: GitHub
  • CI system used: GitHub actions
  • Scanner command used: 
    • Run SonarSource/sonarqube-scan-action@v4
  with:
    args: -Dsonar.pullrequest.branch=ALP-1284 -Dsonar.pullrequest.key=52 -Dsonar.pullrequest.base=main -X
  
    scannerVersion: 6.2.1.4610
    scannerBinariesUrl: https://binaries.sonarsource.com/Distribution/sonar-scanner-cli
  env:
    pythonLocation: /opt/hostedtoolcache/Python/3.9.23/x64
    PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.9.23/x64/lib/pkgconfig
    Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.23/x64
    Python2_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.23/x64
    Python3_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.23/x64
    LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.9.23/x64/lib
    GITHUB_TOKEN: ***
    SONAR_TOKEN: ***
  • private repository
  • Log messages: 
    • Run ${GITHUB_ACTION_PATH}/scripts/run-sonar-scanner-cli.sh -Dsonar.pullrequest.branch=ALP-1284 -Dsonar.pullrequest.key=52 -Dsonar.pullrequest.base=main -X
+ sonar-scanner -Dsonar.pullrequest.branch=ALP-1284 -Dsonar.pullrequest.key=52 -Dsonar.pullrequest.base=main -X
13:23:21.261 INFO  Scanner configuration file: /home/runner/work/_temp/sonar-scanner-cli-6.2.1.4610-Linux-X64/conf/sonar-scanner.properties
13:23:21.265 INFO  Project root configuration file: /home/runner/work/io.planer.service.automaticplanning.sense_check/io.planer.service.automaticplanning.sense_check/sonar-project.properties
13:23:21.283 INFO  SonarScanner CLI 6.2.1.4610
13:23:21.285 INFO  Java 17.0.12 Eclipse Adoptium (64-bit)
13:23:21.286 INFO  Linux 6.11.0-1018-azure amd64
13:23:21.292 DEBUG Scanner max available memory: 1 GB
13:23:21.315 DEBUG uname -m returned 'x86_64'
13:23:21.317 DEBUG Create: /home/runner/.sonar/cache
13:23:21.318 INFO  User cache: /home/runner/.sonar/cache
13:23:21.318 DEBUG Create: /home/runner/.sonar/cache/_tmp
13:23:21.805 DEBUG Loaded [440] system trusted certificates
13:23:22.017 INFO  JRE provisioning: os[linux], arch[x86_64]
13:23:22.046 DEBUG --> GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64
13:23:22.470 DEBUG <-- 403 https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 (424ms, 82-byte body)
13:23:22.470 INFO  EXECUTION FAILURE
13:23:22.471 INFO  Total time: 1.213s
13:23:22.471 ERROR Error during SonarScanner CLI execution
java.lang.IllegalStateException: Error status returned by url [https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64]: 403
	at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callUrl(ScannerHttpClient.java:163)
3

Hi,

403 is a permissions error. This error happens when analysis is just getting started and makes me wonder if your analysis token has expired. A few months ago we implemented a policy of automatically revoking tokens that hadn’t been used in the last, I think it was 60d. Is this project analyzed frequently, or could that be what happened here?

 
Ann

4

Hi Ann, thank you for your kind help.
Okay, this could be the case. What are the next steps then?

5

Hi,

You could generate a new token for analysis of this project, which would get you over the hump today. But when you need to re-analyze in … 3 months(?) you’ll have the same problem. Alternately. You can apply a token that’s being used on other projects as well. Between all of them, it should keep the token “alive” long-term.

The down side of this is that

  1. the token has to be generated from the account of a person with access to all the projects of interest (so it’s a powerful token)
  2. if there’s a problem with the token, you have to remember/find all the projects it’s been configured for to correct it.

 
HTH,
Ann

6

Thanks Ann, I will give it a shot!

1 Like
7

Hi,

It turns out we’re adding “scoped organization tokens” tomorrow. This will let you create a token at the organization level. They won’t be tied to a specific user, so no risk of killing all your pipelines if someone leaves the company.

Looks for the official announcement tomorrow for more details.

 
Ann

1 Like
8

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