14:02:17.693 INFO JRE provisioning: os[linux], arch[x86_64]
14:02:17.734 DEBUG --> GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64
14:02:18.252 DEBUG <-- 403 https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 (517ms, 110-byte body)
14:02:18.262 ERROR Failed to query JRE metadata: . Please check the property sonar.token or the environment variable SONAR_TOKEN.
Steps to reproduce: run pipeline
Following the setup instructions for a new project in a Bitbucket Cloud pipeline we’re receiving the above error. Having looked around other topics I see most related issues include a 403 or 401 error output, but the error message for this failure appears to be a blank space followed by a period, though enabling DEBUG shows the underlying 403.
Mitigation steps tried which resulted in no change:
Adding SONAR_TOKEN as an explicit variable on the pipe step
Adding EXTRA_ARGS: '-Dsonar.host.url=https://sonarcloud.io' variable to the pipe step
Passing SONAR_TOKEN as an unprotected var to validate it was passed correctly (rolled new token afterwards)
Using the same SONAR_TOKEN value locally to validate (successful locally)
Any advice would be appreciated, thanks.
Pipeline script:
image: node:24
clone:
depth: full # SonarQube Cloud scanner needs the full history to assign issues properly
pipelines:
pull-requests:
'**':
- parallel:
steps:
- step:
name: Run Tests
caches:
- node
script:
# Install all dependencies
- npm ci
- cd ops/recovery && npm ci && cd ../..
- cd ops/replication && npm ci && cd ../..
- npm run test:ci
- cd ops/recovery && npm test && cd ../..
- cd ops/replication && npm test && cd ../..
- step:
name: SonarQube
script:
- pipe: sonarsource/sonarcloud-scan:4.0.0
variables:
DEBUG: "true"
- pipe: sonarsource/sonarcloud-quality-gate:0.1.6
The sonarsource/sonarcloud-scan:4.0.0 pipe already knows the correct SonarCloud endpoint internally. The JRE metadata API is at https://api.sonarcloud.io/analysis/jres, not https://sonarcloud.io/``. By overriding sonar.host.url, the scanner may be constructing the JRE metadata URL against https://sonarcloud.io (the web app), which returns an HTML page or redirect that the HTTP client can’t parse into an error message, hence the empty exception message. Have you tried it without the explicit sonar.host.url?
Additionally, in our documentation we recommend a secure repository or account variable. In this case there is no need to specify this variable in the bitbucket-pipelines.yml file. Have you tried it with this construction?
Both of those were added in a attempts to mitigate the issue, as stated. Removing either or both results in the same error with blank reason output. I’ve edited the script to make it clearer that those were only attempted but not current state.
The blank error reason (: . instead of : 403 Forbidden) typically means the HTTP client threw an exception with an empty message, which can happen when the request never completes rather than receiving an HTTP response.
I see that you have already set DEBUG: "true". Can you share the log output of the pipeline run (redacted as needed)?
Debug output should show whether the runner is failing to reach api.sonarcloud.io at all (connection-level failure) versus getting an actual HTTP error back.
I added the short error output to the original post’s bullet points, but here’s the full output minus the Docker setup bits:
19:40:03.011 INFO Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
19:40:03.019 INFO Project root configuration file: NONE
19:40:03.042 INFO SonarScanner CLI 7.0.2.4839
19:40:03.045 INFO Java 17.0.14 Amazon.com Inc. (64-bit)
19:40:03.046 INFO Linux 6.18.35 amd64
19:40:03.060 DEBUG Scanner max available memory: 2 GB
19:40:03.089 DEBUG uname -m returned 'x86_64'
19:40:03.093 DEBUG Using JVM default truststore: /usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts
19:40:03.095 DEBUG Create: /opt/sonar-scanner/.sonar/cache
19:40:03.095 INFO User cache: /opt/sonar-scanner/.sonar/cache
19:40:03.096 DEBUG Create: /opt/sonar-scanner/.sonar/cache/_tmp
19:40:03.200 DEBUG Loading OS trusted SSL certificates...
19:40:03.201 DEBUG This operation might be slow or even get stuck. You can skip it by passing the scanner property 'sonar.scanner.skipSystemTruststore=true'
19:40:03.864 DEBUG Loaded [1029] system trusted certificates
19:40:04.229 DEBUG Loaded truststore from '/usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts' containing 147 certificates
19:40:04.502 INFO JRE provisioning: os[linux], arch[x86_64]
19:40:04.538 DEBUG --> GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64
19:40:05.050 DEBUG <-- 403 https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 (511ms, 110-byte body)
19:40:05.058 ERROR Failed to query JRE metadata: . Please check the property sonar.token or the environment variable SONAR_TOKEN.
org.sonarsource.scanner.lib.internal.MessageException: Failed to query JRE metadata:
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreMetadata(JavaRunnerFactory.java:167)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreFromServer(JavaRunnerFactory.java:140)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.createRunner(JavaRunnerFactory.java:87)
at org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncherFactory.createLauncher(ScannerEngineLauncherFactory.java:54)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:154)
at org.sonarsource.scanner.cli.Main.analyze(Main.java:76)
at org.sonarsource.scanner.cli.Main.main(Main.java:64)
Caused by: org.sonarsource.scanner.lib.internal.http.HttpException:
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callUrl(ScannerHttpClient.java:139)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callApi(ScannerHttpClient.java:123)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callRestApi(ScannerHttpClient.java:104)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreMetadata(JavaRunnerFactory.java:161)
... 6 common frames omitted
19:40:05.061 DEBUG Scanner engine bootstrapping failed
19:40:05.062 INFO EXECUTION FAILURE
19:40:05.064 INFO Total time: 2.055s
✖ SonarQube Cloud analysis failed. (exit code = 1)
The 403 is occurring at the authentication layer before the request reaches the SonarCloud backend, and the blank error message is a side effect of how the HTTP client handles that particular response format.
I noticed you’re currently on sonarsource/sonarcloud-scan:4.0.0, released a year and a half ago, which bundles an older version of the scanner. The latest version is 4.1.0, which includes updates to how the scanner handles authentication with the SonarCloud API.
Could you try updating your pipeline to use 4.1.0 and let us know if that resolves the issue?
- pipe: sonarsource/sonarcloud-scan:4.1.0
Everything else in your configuration can remain unchanged.
Still receiving a 403, but it now contains an error reason:
13:06:51.372 INFO Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
13:06:51.378 INFO Project root configuration file: NONE
13:06:51.407 INFO SonarScanner CLI 7.1.0.4889
13:06:51.410 INFO Java 17.0.14 Amazon.com Inc. (64-bit)
13:06:51.411 INFO Linux 6.18.35 amd64
13:06:51.422 DEBUG Scanner max available memory: 2 GB
13:06:51.465 DEBUG uname -m returned 'x86_64'
13:06:51.470 DEBUG Using JVM default truststore: /usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts
13:06:51.472 DEBUG Create: /opt/sonar-scanner/.sonar/cache
13:06:51.473 INFO User cache: /opt/sonar-scanner/.sonar/cache
13:06:51.474 DEBUG Create: /opt/sonar-scanner/.sonar/cache/_tmp
13:06:51.673 DEBUG Loading OS trusted SSL certificates...
13:06:51.673 DEBUG This operation might be slow or even get stuck. You can skip it by passing the scanner property 'sonar.scanner.skipSystemTruststore=true'
13:06:52.432 DEBUG Loaded [1029] system trusted certificates
13:06:52.777 DEBUG Loaded truststore from '/usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/security/cacerts' containing 147 certificates
13:06:53.158 INFO Communicating with SonarQube Cloud
13:06:53.163 INFO JRE provisioning: os[linux], arch[x86_64]
13:06:53.211 DEBUG --> GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64
13:06:53.689 DEBUG <-- 403 https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 (477ms, 110-byte body)
13:06:53.704 ERROR Failed to query JRE metadata: GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 failed with HTTP 403
{"Message":"User is not authorized to access this resource with an explicit deny in an identity-based policy"}. Please check the property sonar.token or the environment variable SONAR_TOKEN.
org.sonarsource.scanner.lib.internal.MessageException: Failed to query JRE metadata: GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 failed with HTTP 403
{"Message":"User is not authorized to access this resource with an explicit deny in an identity-based policy"}
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreMetadata(JavaRunnerFactory.java:167)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreFromServer(JavaRunnerFactory.java:140)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.createRunner(JavaRunnerFactory.java:87)
at org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncherFactory.createLauncher(ScannerEngineLauncherFactory.java:54)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.buildNewFacade(ScannerEngineBootstrapper.java:197)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrapCloud(ScannerEngineBootstrapper.java:162)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:149)
at org.sonarsource.scanner.cli.Main.analyze(Main.java:76)
at org.sonarsource.scanner.cli.Main.main(Main.java:64)
Caused by: org.sonarsource.scanner.lib.internal.http.HttpException: GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 failed with HTTP 403
{"Message":"User is not authorized to access this resource with an explicit deny in an identity-based policy"}
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callUrl(ScannerHttpClient.java:137)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callApi(ScannerHttpClient.java:121)
at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.callRestApi(ScannerHttpClient.java:103)
at org.sonarsource.scanner.lib.internal.facade.forked.JavaRunnerFactory.getJreMetadata(JavaRunnerFactory.java:161)
... 8 common frames omitted
13:06:53.711 DEBUG Scanner engine bootstrapping failed
13:06:53.711 INFO EXECUTION FAILURE
13:06:53.713 INFO Total time: 2.345s
✖ SonarQube Cloud analysis failed. (exit code = 1)
Thank you for testing the updated pipe, the new error message surfaced something helpful.
The message "User is not authorized to access this resource with an explicit deny in an identity-based policy" indicates that the request is being blocked at the infrastructure level before it even reaches SonarCloud’s application layer. This is distinct from a token authentication failure, your token appears fine given that the same credentials work locally.
On your end, it would be worth checking whether your SonarCloud organization has any IP allowlist configured under your organization’s security settings, as Bitbucket Cloud pipeline egress IPs may be affected by such restrictions.
On our end, I will flag this to the appropriate team to investigate whether there is anything on our infrastructure side that could be causing Bitbucket Cloud pipeline IPs to receive an explicit deny.