Feature improvement: SonarCloud -> GitHub integration

Here’s a suggestion for inprovement.

I have created a SonarCloud GitHub action integration and it works fine when I push code to my repository.

But when DependaBot submits a pull-request and the scan starts , then I always get this error:

“The format of the analysis property sonar.token= is invalid”

So, apparently, after many wasted hours, the problem is in the GitHub action script you generate for me in sonarcloud:

name: SonarQube
on:
push:
branches:
- main
pull_request:
types: [opened, synchronize, reopened]

A solution is to change the trigger from pull_request to pull_request_target or improve the guidance and documentation and perhaps also the generated github action template in SonarCloud.

The problem is that the SONAR_TOKEN secret not provided to the script when dependabot creates the PR.

Or perhaps, include some "helpful hints, in the error message, so guiding developers on how to troubleshoo this.

i wish I didn’t have to waste many hours on this problem.

Hey @tn-dev

My understanding is that pull_request_target runs in the context of the base of the pull request, rather than in the context of the merge commit.

Aditionally:

Avoid using this event if you need to build or run code from the pull request.

So I don’t think that this is the appropriate event to trigger PR analysis, since the SonarQube Scanner should be analyzing the code in the PR.

All of that said,:

I can understand this happening if dependabot is forking the repo and making their changes in the fork before submitting a PR… but in my experience with Dependabot, a branch is created on the repo itself (no fork). And therefore the workflow has access to repo secrets (like SONAR_TOKEN). Does it work differently in your project?

I am only running within my own repository (no Fork).

See

I am not an expert here, but I am not doing anything out of the ordinary, I have a public repo, with dependabot enabled.

Seems after doing some research that pull_request_target, is not the correct way either.

but, then I would like to know, what the recommend way to run sonarcloud when Dependabot creates a PR? As Sonarcloud needs the secret somehow.

Hi!

any update on this? On how to properly integrate Sonar in my PR-checks? What is the correct way to pass my secret token to the PR-workflow?

Hey @tn-dev

I think at this point it would be useful for you to paste your full GitHub Actions YML (using pull_request, not pull_request_target). Sorry for not asking it before

Sure

The script can be found here CloudDebugger/.github/workflows/sonar.yml at main · tndata/CloudDebugger · GitHub

It works great when I do a PR, but when Dependabot does it, it does not work (The secret is not included). So, I wonder if this case is something I should be able to handle? or is it impossible to do safely (to avoid exposing my secrets).

I just want to understand what is possible and if I am doing something wrong. as I get the “The format of the analysis property sonar.token= is invalid” error.

Thanks @tn-dev

Everything in your workflow file looks as expected, and now it’s great to be able to confirm the dependabot PRs aren’t coming from forks.

TBH I don’t see any PRs in this repo before January. Am I missing something?

Would also like to see how you’ve configured SONAR_TOKEN in your repository. Can you share a screenshot?

I’d also like to make sure nothing has been added under Dependabot secrets and variables.

Hi

I haven’t been that active in the project lately, but here is a pull reuest I approved today.

Here are my secrets:

Okay. After reading a bunch of stuff (like this and this) I think what you need to do is actually the opposite of what I said here:

And actually make sure you have added SONAR_TOKEN here.

I am a bit lost on why things are setup this way, but it’s worth trying.

thanks! I added a new token under Dependabot secrets and I will evalutate it the next time dependabot makes a PR.

It could perhaps be good if the documentation around this (GitThub Dependabot + Sonarqube) was updated…

Yes, it works under “Dependabot secrets and variables.", :slight_smile: Finally! Perhaps the documentation/online wizard to be more clear and helpful about this? Or if the tool, it self, in the error message, gave some hint about how to solve it.

It’s a weird case I’m surprised we don’t hear about more often. I’ll flag it for attention and see what other think makes sense.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.