it seems to be the latest release v5.
guerlielton-nunes said that the workaround is set the version to sonarsource/sonarqube-scan-action@v1.2.0 which uses cli-4.
it seems to be the latest release v5.
guerlielton-nunes said that the workaround is set the version to sonarsource/sonarqube-scan-action@v1.2.0 which uses cli-4.
This is not an outage , this was a bad release that overwrote an existing docker tag that impacted downstream dependencies (that should not need to be touched after 8 months).
Using v2.0
does not fix the issue. v1.2.0
does bypass this specific issue, however that version has other compatibility issues and should not be considered a valid work around. Please fix this asap.
Can confirm, 2.0 doesnāt fix it.
As a temporary solution, canāt you just rerun the release from 8 months ago to re-override the tag that was overridden in the first place and then proceed to fix the actual issue with the latest? Some people, including myself, may have stringent rules in place to only allow certain versions of actions within workflow files and switching to a new SHA or previous version (like 1.2.0
which actually works, versus 2.0
as mentioned which still suffers the same problem as it is pointing to 5.0.1
of the cli) isnāt an easy or quick option.
Downgrading causes dependency issues in my workflow
Downgraded to SonarSource/sonarcloud-github-action@v1.9.1 from masterā¦
ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: The plugin [python] does not support Java 11.0.20
Caused by: java.lang.UnsupportedClassVersionError: org/sonar/plugins/python/PythonPlugin has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
Just tried v2.0.2 and it works
Hi all,
Weāve restored a working version of the underlying Scanner CLI Docker image.
This should now be fixed for everyone.
Sorry, again, for the inconvenience.
Ann
Could you all provide a postmortem once the dust settles?
Hi @mattbangert,
We do internal post-mortems after every incident, but we donāt usually publish them.
What I can tell you today is that
I expect the retro to focus on items 2 and 4 above.
Ann
The fix has been applied!
@ganncamp in my org, we often pin GitHub actions to avoid similar issues
uses: sonarsource/sonarqube-scan-action@69c1a75940dec6249b86dace6b630d3a2ae9d2a7 # v2.0.1
Unfortunately, that didnāt help in this case, as the action itself did not pin its reference to the sonarsource/sonar-scanner-cli:5.0.1
image. Would you consider doing that for future action versions?
Hi @GreyTeardrop,
I think everything will be up for grabs in the retro.
Weāre definitely aware of the pain this caused, and it was all-hands-on-deck yesterday (the Europeans got called back to their desks from dinner) to get this addressed. We are going to figure out how to prevent this in the future.
Ann
I did not see any follow up on this incident. The Dockerfile base image is still hard coded making it the action vulnerable to this kind of failure in the future. Is there any plan to change this or introduce any other preventative measure?
Hi all,
Since this is the first time weāve posted a retro followup publicly, we donāt have a lot of machinery established around it. So Iām just posting here:
Following a SonarScanner CLI Docker release on April 16, 2024, GitHub Actions and GitLab Workflow users could not use SonarQube or SonarCloud to perform code analysis in their build pipelines for a few hours.
What caused the issue?
The problem was triggered by the release of a new SonarScanner CLI Docker image to address vulnerabilities discovered in this Docker image. Because of the versioning scheme in place at the time, Sonar published the new Scanner CLI Docker image using the previously released version number, which caused the new release to replace the prior version.
While the new version addressed the SonarScanner CLI Docker image vulnerabilities, we unintentionally introduced changes that broke the images built on top of it. This included removing ROOT access on the image and removing packages that were not necessary for Sonar use cases. This impacted Sonarās GitHub Actions and GitLab Workflows integrations, as the SonarScanner CLI Docker image is the base image for both of these due to a lack of pinned versions.
Restoring GitHub Actions
To fix GitHub Actions and GitLab Workflows, Sonar republished the prior working SonarScanner CLI Docker image version (basically a rollback). This action restored SonarQube and SonarCloud functionality so that GitHub Actions and GitLab Workflows performed as expected.
However, as many users pointed out, this was a short-term solution that did not prevent the issue from happening again, and we recognize that replacing existing versions is a bad practice.
Long-term fix implementation
On May 21st, Sonar released a new version of the SonarScanner CLI Docker, patched against the following vulnerabilities (CVE-2018-20225, CVE-2024-0853, CVE-2024-2511, CVE-2023-3635). Also, Sonar can now deliver changes for the Scanner Docker CLI and flip the version only for the dependent stacks after testing the impact.
Additionally, Sonar has implemented several changes to prevent this issue from occurring again. This includes the following:
We acknowledge that this caused significant disruption and presented a security risk for Sonar users and would like to apologize again for any inconvenience the outage may have caused.
Thank you.