I am seeing issues with a PR that is reporting PHP Code Sniffer errors incorrectly compared to a full repo can locally, either with the Codacy Docker image or with PHP Code Sniffer directly locally. I can see online that it is incorrectly reporting errors that it shouldn’t be checking and aren’t according to the standards that are being installed via Composer.
The plot thickens as I moved the
phpcs.xml.dist to the repository root and now I’m getting an error about not finding the PHPCompatibilityWp ruleset:
KubernetesDockerRunner: Container for codacy/codacy-codesniffer:2.4.9 exited with non-zero code 1
Error executing the tool
CodeSniffer exited with code 3
stdout: ERROR: Referenced sniff “PHPCompatibilityWP” does not exist
It seems like there are major differences between using the Codacy CLI Docker image and how Codacy actually runs online. This makes testing and setup a real major pain. Locally the Codacy CLI reads the
base_sub_dir but online it seems as though Codacy ignores this as the root for the tool to run, including using the
phpcs.xml.dist in that directory.
Digging into prior commits where I was seeing problems with Codacy not picking up the rules I find that both PHP Code Sniffer & ESLint are erroring out in the logs and not actually running correctly online.
It appears, looking at another of our projects, that Codacy supports the
PHPCompatibility rules but not the additional
PHPCompatibilityWP rules we install via Composer. Is Codacy completely doing it’s own thing for installing/supporting PHP Code Sniffer rules?
BTW, that custom WordPress ruleset is here: GitHub - PHPCompatibility/PHPCompatibilityWP: PHPCompatibility ruleset for WordPress projects
Thank you for reporting this! You are correct, PHPCompatibilityWP is not one of our currently supported plugins - I have opened an internal ticket with our team so that we can add this plugin and I will post an update here once it has been added
In the meantime, you can find the PHP Code Sniffer plugins we currently support here.