401 during GH workflow of Gradle sonar task with SonarCloud

I am running into a 401 running the Gradle sonar task when it comes to accessing the Sonar Cloud API server. The problem occurs with the 6.x relase of the Gradle plugin and only in my GH Action.

Executing it locally or with the latest 5.x release of the plugin is no problem.

In detail

Execution failed for task ':sonar'.
> java.lang.IllegalStateException: Error status returned by url [https://api.sonarcloud.io/analysis/jres?os=linux&arch=x86_64]: 401

Hey there.

How are you providing authentication to the scanner? With SONAR_TOKEN, or some other way (somehow including the info in a build.gradle file, etc.)

  - name: Build and analyze
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    run: ./gradlew build sonar --info

It would be useful to see your full GitHub Actions Pipeline YML!

Thanks for the fast feedback, @Colin, and sorry for not directly referring to the workflow file.
If I can somehow assist in further testing, please reach out. I guess we should be able to see the behaviour on a fork or perhaps pull-request.

Hey @ascheman

I’m going to go out on a limb here and say that while you reference SONAR_TOKEN in your workflow file, it might not actually have a value defined.

##[debug]Evaluating: secrets.GITHUB_TOKEN
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'GITHUB_TOKEN'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Evaluating: secrets.SONAR_TOKEN
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'SONAR_TOKEN'
##[debug]=> null
##[debug]Result: null

I believe you need to set SONAR_TOKEN to a valid token in your repository variables/secrets.

Of course, that’s clear. I was also wondering why I do not even see the usual *** for a hidden secret in the output. However, the pipeline works with the Sonar 5.x Gradle plugin, but fails with 6.x without any other change.

I have explicitly set a new token as secret SONAR_TOKEN:

But it does not show up in the debug output.
Even if I delete it, the workflow works like a charm with Sonar 5.x.

Perhaps a GH action problem?

But what is even more strange: I have tried to run the sonar analysis locally and didn’t set a SONAR_TOKEN environment variable.

  • Works fine with Sonar 5, but
  • Does not work with Sonar 6!

What other means of authentication are there?
Setting a valid SONAR_TOKEN makes no difference.

@ascheman I think there’s two things going on.

  1. For either your project/organization, you probably have Execute Analysis permissions set to Anyone. This is a very bad idea, because it means that anybody (authenticated to SonarQube or not) could run an analysis against your project. Eventually, we want to get rid of this option altogether.

  2. So why is it working with v5 of the Scanner for Gradle but not v6? Probably an error on our part. v6 of the Scanner for Gradle calls an API (to support JRE auto-provisioning) that requires authentication, even if you have granted the Execute Analysis permissions to Anyone.

    Now, this isn’t great – SonarQube Cloud should do what it says it will do (allow anybody to execute analysis). I’ll raise that as an issue for our team to look at. With that being said, I really don’t recommend that you allow anyone to execute analysis.

Now, I still don’t know why, when you set SONAR_TOKEN, you don’t see it configured correctly. In my runs, I see the *** I expect to see.

2024-12-19T12:36:59.2206554Z ##[debug]..Evaluating String:
2024-12-19T12:36:59.2206679Z ##[debug]..=> 'GITHUB_TOKEN'
2024-12-19T12:36:59.2207163Z ##[debug]=> '***'
2024-12-19T12:36:59.2207380Z ##[debug]Result: '***'
2024-12-19T12:36:59.2208024Z ##[debug]Evaluating: secrets.SONAR_TOKEN
2024-12-19T12:36:59.2208126Z ##[debug]Evaluating Index:
2024-12-19T12:36:59.2208216Z ##[debug]..Evaluating secrets:
2024-12-19T12:36:59.2208328Z ##[debug]..=> Object
2024-12-19T12:36:59.2208433Z ##[debug]..Evaluating String:
2024-12-19T12:36:59.2208527Z ##[debug]..=> 'SONAR_TOKEN'
2024-12-19T12:36:59.2208768Z ##[debug]=> '***'
2024-12-19T12:36:59.2208938Z ##[debug]Result: '***'

If I were you, I’d try setting some other variables and seeing if you get the same results (do they show up as null or ***? Is it specific to the Gradle step or does it happen in other steps as well?)

1 Like

Thanks a lot, @Colin. Will take care of the project permissions in the next days and dig deeper into the secret invisibility as well.

Regarding the debug output you sent: Is it from our project, e.g., from a fork or from something else?

No, just my own project.

Could you elaborate a little more on why you consider allowing anyone to “Execute [the] Analysis” is a bad idea, @Colin?

In this case this is an OSS project. I would like to allow anyone to execute the analysis for their changes. It shouldn’t matter whether they start the Sonar plugin from a PR or from their local machine. We would like to find possible issues as early as possible (and not first merge them).

If anybody can execute an analysis against your project, anybody who points an analysis at your main branch can overwrite it.

That can be by accident (developer who forgets to set sonar.branch.name) or intentional as a nuisance (or worse, imagine somebody who finds a vulnerability in your project and runs an analysis excluding that file from detection so that it goes undiscovered for longer).

Suggesting that developers use SonarQube for IDE to detect issues early, and using Automatic Analysis on your project is preferable if you have a lot of external contributors.

Thanks again for your fast reply, @Colin.

I wonder a little bit, whether those are not separate concerns which could be split up during Analysis execution and therefore also in the permission schema.

  • As an arbitrary contributor or during the PR execution (from a fork) I would like to check whether my changes violate the quality gates (and thus would break the build on a regular/trunk branch, e.g., main or master). Then the execution of the sonar task should break the build. But the results need not to be published to the Sonar Server (-Cloud).
  • As a project committer and maintainer I would like to se some report of the status on the public SonarCloud project page for my branches (from a non-forked project).

So what I am missing is an opportunity to read the respective information (configured Quality Gate for example) to analyse the build and make it success or fail. This seems not to be possible when dropping the “Execute Analysis” permission and not authenticating via token (Error Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator to check the permissions of the user the token belongs).

The documentation says I would need some browse permission for non-public projects which seems to be given implicitly for public projects.

So, is there any way to perform the analysis without a token and without the “Execute Analysis” grant (and of course without upload of results)? If not, would you (SonarQube) implement such an opportunity?

Running analysis without submitting the results to SonarQube (outside of an IDE context with SonarQube for IDE) is just not on our roadmap. We think the experience is best in the SonarQube UI as opposed to a local report, and it makes things like usage-based licensing very difficult to implement.

With all of that being said, we want the experience for open source projects to be a positive one and we know that the experience with external contributors and permissions isn’t always ideal today. I’ll make sure your feedback gets passed along to the right team.

1 Like