Github CI/CD getting inconsistent 403 errors on JRE metadata

SonarQube Cloud
1
  • ALM used Github
  • CI system Github Actions
  • Language used Typscript/Javascript
  • Example of failure add objectfit tests · ir-engine/ir-engine@a03f202 · GitHub
  • ERROR Failed to query JRE metadata: GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 failed with HTTP 403. Please check the property sonar.token or the environment variable SONAR_TOKEN.
  • Sadly no steps to reproduce other than running it. It happens randomly and not all the time but is creating a lot of inconsistent results with SonarQube due to missed scans.

Some extra details is that since we’re a monorepo I set it up to be individual projects. Not sure if we’re hitting some invisible limit. Have not been able to find a similar topic. Maybe the GITHUB CI/CD is failing to pass the secret sometimes. I am unsure at this point.

2

Hi,

Welcome to the community!

You say this behavior is inconsistent. Does that mean that for any given project sometimes it fails and sometimes it succeeds? Or are the errors, perhaps, clustered in specific projects?

 
Ann

3

Hello Ann,

Thank you!

Any given project it fails randomly. I can update a PR and it will be one or more of the jobs that fail or it will all succeed. Gathering some data I can see it happens possibly significantly more on our test client jobs. But I’ve seen it happen on every SonarQube job we have since we implemented them recently.

4

Hi,

Given the inconsistency, I suspect something “helpful” on your network is interfering. I would start by checking your $SONARQUBE-HOME/logs/access.log` to see if the calls actually make it to SonarQube and it’s SonarQube actually returning the 403s.

 
HTH,
Ann

5

Hey,

I’m not seeing any /logs/ being populated by the SonarQube action. I looked through the source of the action and nothing stands out. I’ve logged every possible sonar location on the runner. I’ve figured out how to enable --debug with the action and that’s giving some details. Trying to get it to fail again with that flag. Tried logging out ubuntu NetworkManager logs. Not really sure how else to gather this network data.

Daniel

EDIT: SonarQube Logs · ir-engine/ir-engine@b93f6fc · GitHub got it to finally fail with debug logging.

1 Like
6

Was able to reproduce with a curl right after the failure. Pretty sure it’s coming from sonarCloud services. Specifically the AWS ELB

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host api.sonarcloud.io:443 was resolved.
* IPv6: (none)
* IPv4: 3.121.62.27, 3.67.112.73, 18.185.150.164
*   Trying 3.121.62.27:443...
* Connected to api.sonarcloud.io (3.121.62.27) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3846 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / prime256v1 / rsaEncryption
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=sonarcloud.io
*  start date: Feb  4 00:00:00 2025 GMT
*  expire date: Mar  6 23:59:59 2026 GMT
*  subjectAltName: host "api.sonarcloud.io" matched cert's "*.sonarcloud.io"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
{ [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://api.sonarcloud.io/analysis/jres?os=linux
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.sonarcloud.io]
* [HTTP/2] [1] [:path: /analysis/jres?os=linux]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [authorization: ***
} [5 bytes data]
> GET /analysis/jres?os=linux HTTP/2
> Host: api.sonarcloud.io
> User-Agent: curl/8.5.0
> Accept: */*
> Authorization: ***
> 
{ [5 bytes data]
< HTTP/2 403 
< server: awselb/2.0
< date: Fri, 18 Apr 2025 21:26:20 GMT
< content-type: text/html
< content-length: 118
< 
{ [118 bytes data]

100   118  100   118    0     0    206      0 --:--:-- --:--:-- --:--:--   206
* Connection #0 to host api.sonarcloud.io left intact
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>
7

Hi,

Thanks for the error log. I’m going to flag this for more expert eyes.

 
Ann

9

Thank you so much,

Excited to find a solution for this. Has been difficult using Sonar since our baselines sometimes fail and other PR’s get blamed for the new code.

1 Like
10

I’m experiencing this in my pipelines (feat: add `WithReuseByName` for modifying Generic Container Requests … · testcontainers/testcontainers-go@8a498b7 · GitHub), and it’s particularly weird that it breaks them in a non-deterministic manner. Thankfully this community found the root case

12

Happened to me as well today. Fix a critical bug: wrong symbol for production deployment · ewancoder/nitrotype-tracker@f4066f0 · GitHub

20

We’re new to GitHub Actions and we’re seeing this issue consistently when trying to migrate our java pipelines :frowning:

Bizarrely it works locally using the same SONAR_TOKEN, but not on GitHub actions. Secrets are setup correctly :man_shrugging:

 Failed to query JRE metadata: GET https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64 failed with HTTP 403. Please check the property sonar.token or the environment variable SONAR_TOKEN.
21

Hi all,

Sorry it’s been so long with no update on this.

Our investigations show that the IPs that are used in Github Actions are blocked in AWS due to its reputation (maybe someone used the same actions for some suspicious activity and AWS added them in the block list).

Unfortunately, we’re all kinda in the middle here.

Probably the best course is that you each raise this with GitHub.

 
Ann

22

Yeesh, that sucks :sleepy_face: I’m not even using GitHub action runners :melting_face:

23

Hey!

Happy to hear back! That’s a fairly tough outcome. Appreciate the investigation. I thought this might be the case but was hoping it was as easy as whitelisting some IP’s in your cloud config. Seems like we’re stuck in a AWS vs Azure situation. We’ll try to contact Github. Maybe we can host our own runner elsewhere.

Thanks Again,
Daniel

1 Like