Add archive check workflow

[AlexP11223]

Please check if the PR fulfills these requirements

• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce?
feature (new workflow)

The workflow runs some checks on the plugin archive to make sure that everything is ok (especially important if processing the source code via php-scoper or Rector).

It executes Parallel Lint to check the PHP syntax, and Plugin Check phpcs ruleset, as well as other specified WP sniffs (by default I18n, because in some cases the translators: comments can be deleted by php-scoper).

It clones the Plugin Check repo and installs its composer deps, this seems to be the only quick way to use Plugin Check without WP and Docker, and it's a simple way to get phpcs and WP sniffs, since the plugin archive does not include the dev deps.

One issue here is that phpcs CLI is more limited than the config file. For example it’s not possible to ignore only the exception escaping errors when running the escaping sniff. But copying and maintaining the config for archive checking in each plugin seems like too much work, so for now trying like this.

[luislard]

One issue here is that phpcs CLI is more limited than the config file. For example it’s not possible to ignore only the exception escaping errors when running the escaping sniff. But copying and maintaining the config for archive checking in each plugin seems like too much work, so for now trying like this.

Don't know if it is your use case, or if you really need it, but, see how we added a default config file here,

[Chrico]

We already have a reusable workflow for this: https://github.com/inpsyde/reusable-workflows/blob/main/.github/workflows/lint-php.yml

[AlexP11223]

I think I put it here because the workflow cannot run on the extracted artifact. Though the new unified build may solve that.

[Chrico]

@Biont and @AlexP11223 , what is the status of this PR?

[Biont]

I think the installation and usage of the Plugin Check package is worth revisiting. The current approach is pretty much a ship of theseus in that we

• set up a generic php environment
• download the dev version of the plugin
• extract the rules we need
• execute them outside of the plugin

I think given that the plugin ships with a ready-to-use wp-env, we could instead try to mount our plugin artifact into it and then run the official wp-cli command.

This would ensure maximum forward-compatibility in case they ever add more sophisticated check than just phpcs.