[ERROR] Not authorized or project not found. Please check the 'SONAR_TOKEN' environment variable, the 'sonar.projectKey' and 'sonar.organization' properties, or contact the project administrator to verify the token's permissions.

[pdurbin]

While reviewing the following #12551 I noticed the following error:

At https://github.com/IQSS/dataverse/actions/runs/30493484094/job/90717789386?pr=12551 I'm seeing the following error:

[ERROR] Not authorized or project not found. Please check the 'SONAR_TOKEN' environment variable, the 'sonar.projectKey' and 'sonar.organization' properties, or contact the project administrator to verify the token's permissions.

Here's a screenshot:

This certainly results from our recent addition of a Sonar check:

• Add SonarQube analysis and coverage reporting to GitHub Actions #12550

I'm assuming the failure above happened because the pull request came from a fork.

How should we handle this? In this case @qqmyers is a member of the core dev team, so should we ask him to set up the credentials in his fork?

For random contributors, should we update the pull request template and dev guide to set expectations that this error is expected?

[poikilotherm]

Option A - Disable for PRs from forks and branches in forks

Simple.

Option B - Enable running Sonar in upstream repo context to have access to the SONAR_TOKEN secret

Not so simple. The hardest part: while we run any of this, we need to collect the results from the different test that ran. This is easy to do if within the flow, but harder when we have to figure out which runs may have something to report.

Aside from that, there is an option to use a comment-command (see also how we do preview images from forks), we could use the pull_request_target trigger (kind of endangering secrets when running unmoderated) or some other clever trigger around "workflow_run" (example).

If you query a search engine for "Sonarcloud", "fork" and "PR", you will find quite a bunch of people stuck with the same problem and not a lot of solutions. Unfortunately, neither of them being "easy" or "simple".

BTW - The official way to solve this is "Automatic Analysis", where scanning happens on the Sonarcloud side of things. Unfortunately, our codebase is way past their limits - we must use the CI method.

This also reminds me of how we have reviewdog bark on some PRs, with the same problem: with PRs from forks we have no access to leave a review. Might be good to keep in mind if we're interested in having auto-reviews from Sonar in contributions.

[pdurbin]

@poikilotherm thank for implementing Option A in the following PR!

• Limit SonarQube job to upstream repository #12576

Merged! 🚀

Obviously, Option B is preferable, some day! 😅