Sonarqube-quality-gate-action - make it work without local scanMetadataReportFile

Hi,

We are using SonarQube Enterprise Edition v2025.4.2 (112048) on premise, with Github Enterprise 3.19.2, and we are happily using sonarsource/sonarqube-scan-action and sonarsource/sonarqube-quality-gate-action in our Github Workflows, for different languages (Java, .Net, PHP, Docker, etc), following the provided documentation and it is working fine.

Still.

We have a usecase that is not covered, stucked by the behavior of sonarsource/sonarqube-quality-gate-action that is binded to the need of a local scanMetadataReportFile , and I just don’t understand why.

The usecase is that we would like to have some dedicated workflows that just check the Quality-Gate Status of a project, without running any scan.
Because in our workflows, the scan would have necessarily already been done previously, elsewhere.
So we don’t want to pay for any more scans… (it just burns ressources for nothing - green IT is important :seedling: )

So the question is ;
would it be possible to make the sonarsource/sonarqube-quality-gate-action be just what it is ; just a check of that Quality-Gate-Status without the binding of a local scan ?
With the proper project ID, SonarURL and Token, and maybe other variables like a branch-name or tag or commit-hash ; I expect this action to be able to work without any need of a scanMetadataReportFile

It is possible to do this ?

Just to clarify my point of view

Technicaly we can perform this task with the following call to the API within our GithubAction worflow


        steps:
            - name: Call SonarQube Quality Gate API
              run: |
                response=$(curl -w "\n%{http_code}" -s -X GET "${{ vars.SONAR_HOST_URL }}/api/qualitygates/project_status?projectKey=${{ vars.SONAR_PROJECT_ID }}" -H "Authorization: Bearer ${{ secrets.SONAR_TOKEN }}" -H "Content-Type: application/json")
                http_code=$(tail -n1 <<< "$response")
                echo "http_code: $http_code"
                body=$(sed '$ d' <<< "$response")
                echo "Response: $body"
                status=$(echo "$body" | jq -r '.projectStatus.status')
                echo "Status: $status"
                if [ "$http_code" -ne 200 ]; then
                  echo "Error: HTTP request failed with status code $http_code"
                  exit 1
                fi
                if [ "$status" != "OK" ]; then
                  echo "Error: Quality gate status is $status"
                  exit 1
                fi

But this rely on a custom home-made code, that may fail someday for whatever reason (if the SonarApi change, or whatever), and this is dramatically changing the responsability on our own shoulders.

I would feel better if the responsability comes back to SonarQube itself, and I think that the sonarsource/sonarqube-quality-gate-action could really be a good place to handle this, with some little changes.

Hi,

In your followup, you’ve already acknowledged and dismissed what I was going to propose. I’ll say that the API in question is pretty stable, but I understand your point.

Could you share a little more about your use case and why you need to check Quality Gate status unrelated to a build?

 
Thx,
Ann

Hi @ganncamp

Oh, our usecase is quite straitforward and the Quality-Gate check is related to a build.

But the fact is that we are using a CI/CD mecanism that doesnt necessarily “rebuild” an artefact that would already have been built before.

For example, let’s say that we build and publish the commit hash abcdef, the code would be analysed and the Quality Gate would have been checked, and the artefact deployed to our registry, and may be deployed to our sandbox environment.

This workflow is executed for each commit push, and the builded artefact is tagged base on its commit hash.

Then, later on; one person selects one commit hash, lets say fedcba and push a version tag on it, lets say v1.2.3.
We do not have to build it again, since the artefact is already stored on our registy. But we do a kind of promotion by storing the artefact into another location within our registry in which the same object is now know with 2 tags fedcba and v1.2.3.

Before the deployement of this artefact into our staging environment, we want to perform a Quality-Gate check.

We know for sure that we want to check the same artefact that the Quality Gate is already known and stored into SonaQube, so the quality gate is related to a build , but the workflow-itself is totally unrelated to any kind of build ; We don’t wanna build it again, this is useless.

Hi,

Yeah, I completely agree with you about rebuilding. It’s your manual, after-the-fact selection that I think is new to us.

As you’re aware, we don’t support your use case via actions today. I’ll flag this for the PMs.

 
Ann