Scanner command used when applicable - GH action “sonarsource/sonarcloud-github-action@master” with basic configuration.
Languages of the repository - PHP, JS, SQL
Error observed:
14:57:32.588 INFO: Importing /github/workspace/phpstan-report.json
14:57:32.747 INFO: Sensor Import of PHPStan issues [php] (done) | time=159ms
14:57:32.747 ERROR: An error occurred when reading report file ‘/github/workspace/phpstan-report.json’, no issue will be imported from this report.
UnsupportedOperationException: null
About 2 weeks ago (to be precise on June 20th between 14:40-14:46 AMS) our CI configured Sonar scanner started skipping the generated phpstan report.
It happened between two runs in different branches. There were no changes in configuration, or apps updates, or libraries updates. Before that time everything was ok, after that time - we get the abovementioned error in any branches (old or new ones).
Debug mode doesn’t add more information.
How can we get more information about the error and how to fix it?
Since I was just setting up PHPstan for the first time I decided to try Psalm instead. I’m seeing the exact same error with Psalm:
INFO: Importing /github/workspace/psalm-report.json
ERROR: An error occurred when reading report file ‘/github/workspace/psalm-report.json’, no issue will be imported from this report.
This makes me pretty confident that this is NOT a problem with the formatting of the files but something broken in the code that pulls in these reports, especially since these sensors share a base class.
The current code logs the error message and the exception, but none of the details that you’d need to understand why that error was thrown. Maybe logging the stack trace at the debug level would make it easier to solve these issues.
@Marcin_Stachniuk any suggestions? It sounds like this has been broken for weeks, I’d really like to get this going. Is there a better channel for these kinds of support issues for paying customers? I know we are on a paid plan, I’m happy to go figure out what kind of support contract we might have if that will help.
Hey @Marcin_Stachniuk thank you for opening that ticket! I think it might be worth noting in the ticket that it is happening not with just PHPstan but with Psalm as well, so I think it is unlikely to have anything to do with the format of the PHPstan report or the version of PHPstan. I just note this because it may help your dev team track it down more quickly.
I also tried going back to some older versions of the scanner to see if it was maybe an issue with a newer version, but I’m seeing the same errors. So I’m thinking it might be something on the server side.
Hey @Marcin_Stachniuk and @Colin, I’d like to express my disappointment at being featured in the community roundup email I received today. Not because I don’t appreciate the visibility but because the summary in the roundup repeats the same misconception that exists in the issue that Marcin created, which leads me to believe that neither of you actually looked at the additional information I provided.
As I pointed out in the second message I posted 9 days ago, the issue appears to affect not just every PHPstan report I’ve been able to test but Psalm reports as well, which I’d bet money means it has nothing to do with the specifics of the PHPstan report format. Because of this, your team appears to be treating it as an issue that can be worked around on our end, rather than a case of this being completely broken.
I want to make that clear because it doesn’t appear that anyone has actually looked at it yet and I’d expect the priority to be a bit higher considering the additional information I’ve provided. If it is NOT totally broken and is in fact working for some people, I’d really appreciate if someone can let myself and the original reporter know an effective workaround, because I’d really like to start seeing some linting reports for this project.
My company is paying for this service, and while I haven’t checked to see if we have a support contract, I’d expect a tiny bit more responsiveness than this to a paying customer. Nine days is a long time for something to be completely broken with no sort of update as to when we might expect to see a resolution.
I understand your frustration that this feature isn’t working. On closer look, it looks like you’re right, it’s not working for any report (at least none that I’ve tried)! That probably means there’s no workaround we can suggest. I’ve updated the Community Roundup to reflect this.
While we can’t address every issue immediately, I can confirm we will investigate it the next time we work on our PHP analyzer (probably at the beginning of August). In the meantime, the rest of our PHP analysis should still be functional, and you’ll just be missing the import of external reports.
If getting support through this community doesn’t meet your organization’s needs, feel free to look into Sonar Commercial Support.
In any case, thanks again for reporting the issue. You can keep an eye on the ticket @Marcin_Stachniuk created for updates.
The issue has been resolved, and the new version of the analyzer has already been deployed to SonarCloud. Please try running your pipelines again with report importing enabled, it should work now.