GitHub Community
A GitHub Workflow that worked fine 3 weeks ago, now doesn't work #210833
🏷️ Discussion TypeQuestion 💬 Feature/Topic AreaActions Runner Discussion DetailsI've got a simple Blazor application I created a while ago, using the Visual Studio Blazor Web App project template. I did nothing with it, except create the app. I was interested in learning how SonarQube would work in our environment. (We have a GitHub Self-Hosted Runner on one of our Windows Servers.) This worked perfectly 3 weeks ago. Today I wanted to add Dependabot alerts, (Dependency Graph is added), and Malware alerts. I did nothing else; all of this was done in the repo's Settings. However, now when I try to run the workflow it fails. Here's a snippet from the log which I ran with debugging:
The only difference I've been able to find on the SonarQube server is 3 weeks ago it was at SonarScanner for .NET 11.3. Now it is at SonarScanner for .NET 12.0. What could be causing this change in behavior? |
Replies: 2 comments 3 replies
|
The root cause is shown directly in the pre-processor warning and HTTP status in your log: Why This Happened
How to Fix
|
|
I saw the use of the term "private project" or "private repo". This project is not a private project/repo. But, since it is in my employer's GitHub Organization, it has a visibility of Internal. Technically, that is not Private. AddendumWhen I go to the SonarQube web UI, then open the project for the repo I'm working with, I do not see either Permissions or Administration > Projects > Management. I'm guessing that I don't have the necessary permissions to see those things. I've asked the guy who manages our SonarQube server about it. Hopefully, I'll get access, so I can make the necessary changes you've said above. However, if they don't do this, then I'll have to scrap trying to use Dependabot, Dependency Graph, and the Malware scan. |
|
The 403 error you are seeing during the Since you mentioned this worked perfectly 3 weeks ago, the most likely culprit is that the token has simply expired (SonarQube tokens often have a default 30-day expiration limit), or the permissions on the SonarQube project were accidentally modified. Here is how you can resolve this:
The upgrade to SonarScanner 12.0 is likely just a coincidence regarding the timing of the token expiring, though newer versions sometimes surface HTTP errors a bit more explicitly. Swap that token out and your workflow should be back to normal! |
|
I've been looking at the SonarQube server's security where one can create a token. (This was news to me, I didn't know that SonarQube could do it.) But before I update the token for this repo, I took a look at where that repo was getting SONAR_TOKEN. It is coming from the GitHub organization the repo is in. This isn't a surprise to me, because I was hoping to use SONAR_TOKEN from the organization. However, what is a surprise to me is someone has updated SONAR_TOKEN at the organization level last week! Who knows how long they gave the expiration date? (Although if they went with the default that would have been 30 days.) I'm wondering if this has anything to do with the problem I'm encountering? And I'm going to try and find out who updated SONAR_TOKEN. |
|
A colleague and I created the SONAR_TOKEN at the repo level, using the SonarQube server's UI and creating it with a type of Project Analysis Token. Then we put it into the repo. It now works fine. Thank you, @shubhgahoi, for your help! |
The 403 error you are seeing during the
beginstep is almost certainly an authentication or permissions issue with yourSONAR_TOKEN, rather than a bug in the 12.0 scanner update. The scanner is trying to reach out to your SonarQube server to download the project's configuration, and the server is actively rejecting the request.Since you mentioned this worked perfectly 3 weeks ago, the most likely culprit is that the token has simply expired (SonarQube tokens often have a default 30-day expiration limit), or the permissions on the SonarQube project were accidentally modified.
Here is how you can resolve this: