@Michael It's possible the code currently has no bugs or code smells, but as we enable more rules, you may start seeing alerts.
Just yesterday I enabled around 127 recommended PHP rules that were previously disabled, so if any issues arise,
they will be flagged. JavaScript rules haven’t been modified yet, but I'm prioritizing enabling all recommended rules,
which could generate additional feedback.

The bot is now back online. Thanks @kostajh .

I did a few optimizations, and they seem to have positively impacted the time it takes to run codehealth checks on Core. I think this is an acceptable margin as it has reduced the average running time from ~20 minutes to ~10 minutes. I have monitored the trend for almost a week and it seems consistent.

Projects that had been dormant for a couple of years were pruned from Sonarcloud and this was among the affected ones. I have recreated the project with the same key. In case of further issues with the repository please feel free to re-open the task.

The generic 404 error fixed.

In T365260#9834477, @kostajh wrote:

In T365260#9834465, @ArielGlenn wrote:

In T365260#9834222, @kostajh wrote:

...

@ArielGlenn I don't think there is much we can do about this. I don't think it's possible to avoid posting a comment back on Gerrit if the job fails. If the syntax errors in the patch are fixed, the Sonarcloud link will work.

Admittedly this is perhaps my bad for not doing a simple php -l beforehand. But I will sometimes forget that, and I will sometimes push up a broken change. It would be nice if I could at least get told "hey try linting your stuff" instead of the generic 404 error.

@pwangai maybe we could change the error message to something like "The patch was not checked with SonarQube, probably because of PHP linting errors" and also not show the URL to sonarcloud.io, since it doesn't work in that situation.

@kostajh kindly deploy the change as I do not have ssh access to the tool. Maybe after deploying, you can add me to the group tools.sonarqubebot to enable me deploy a change next time

My PHP tool encountered this problem where nodejs would be installed but PHP wasn't. The issue is now fixed, and my tool builds and deploys as it should now. Thanks @dcaro for the fix.

It seems to be working fine with our sonar scanner version. We can go ahead and update extensions Jenkins jobs.

Thank you @hashar I will monitor the codehealth jobs to ensure they are running smoothly.

It appears they are enforcing the minimum scanner version that can be used with Java 17 to be version 5.x. Although from limited research I have seen some who had scanner v4.8^ could run it in Java 17. We can only know for sure by trying after we have a Java 17 image available.

As an aside, I've always wondered if there's any value in running code coverage via SonarCloud in addition to the bespoke CI job. The coverage generated by SonarCloud has several shortcomings such as:

• It's based on unit tests, and ignores integration tests
• It's not published on doc.wikimedia.org
• It doesn't work well with stacked patches

@Aklapper : Thanks, I will make sure to add the project tags in future.

Sonar can use any node version as long as its not a deprecated version. Inherit from our standard node16 image seems like the most optimal way to go :)

This issue has been resolved in T348724: Update sonar scanner node version from v14 to v16 .

For the moment I have changed CheckUser's quality gate to not give coverage alerts until we figure out the coverage issues

One can set the path manually under the project settings (Your Project > Administration > General Settings > Languages > PHP > Tests and Coverage > Files)