GitHub workflows: parity with Core

[anton-vlasenko]

Please, don't merge this PR yet, as some Github actions have to be set as required before merging this PR.

What?

This PR aims to:

1. Ensure parity between Gutenberg and WordPress linter checks to ease backporting efforts.
2. Rename Gutenberg GitHub workflows so that they match Core GitHub workflows.

Why?

1. Having a similar set of CI jobs between the two repositories will help with maintenance, future audits, and switching between the repositories.
2. Ease backporting efforts by ensuring that Gutenberg uses the same (or stricter) set of linter rules compared to Core.

How?

1. Remove the Unit Tests workflow and the unit-test.yml file.
2. Move the PHPUnit CI job from unit-test.yml to phpunit-tests.yml.
3. Move the JavaScript Tests from unit-test.yml to javascript-tests.yml.
4. Rename the Static Analysis (Linting, License, Type checks...) workflow to Coding Standards and moves it to coding-standards.yml.
5. Move the PHP coding standards job from unit-tests.yml to coding-standards.yml.
6. Rename the All job to JavaScript coding standards and move it to coding-standards.yml.
7. Rename the JavaScript job to Jest Tests.
8. squizlabs/php_codesniffer, phpcompatibility/phpcompatibility-wp, and wp-coding-standards/wpcs` packages now use the same package versions as in Core.

Testing Instructions

1. Make sure that the CI jobs pass.
2. Don't pay attention to the Waiting for status to be reported messages as these jobs were removed and other jobs were created to replace them.

Please, don't merge this PR yet, as some Github actions have to be set as required before merging this PR.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

Flaky tests detected in 599bfb6.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4297013819
📝 Reported issues:

• [Flaky Test] should be able to create an hierarchical post without title support #36939 in specs/editor/plugins/custom-post-types.test.js

[oandregal]

While working on porting changes from core back to Gutenberg at #48624 I realized there are some lint checks that differ in the two codebases. Searched for issues/PR and this came up. I wanted to leave a note for using that class as a test case, in case that helps.

[anton-vlasenko]

@oandregal

While working on porting changes from core back to Gutenberg at #48624 I realized there are some lint checks that differ in the two codebases. Searched for issues/PR and this came up. I wanted to leave a note for using that class as a test case, in case that helps.

Thanks for flagging this issue. I'm not sure if it's due to linter checks because currently, both repositories use almost the same set of linter rules. However, I will check it. Thank you!

[oandregal]

Ah, I realize now that I should have provided better examples, sorry. These are the two I ran into:

• Generic.Commenting.DocComment.LongNotCapital: core vs gutenberg.
• Squiz.Commenting.BlockComment.NoEmptyLineBefore: core vs gutenberg.

What I've done to test is: copy the class from core into the gutenberg file. Run the npm run lint:php lib/class-wp-theme-json-gutenberg.php command.

Hope this helps!

[anton-vlasenko]

Thanks for elaborating on your initial comment, @oandregal.
The sniffs you mentioned are enabled in the WordPress-Docs ruleset:

1. Generic.Commenting.DocComment.LongNotCapital
2. Squiz.Commenting.BlockComment.NoEmptyLineBefore

Even though WordPress-Docs is not currently used in Core, it is used in Gutenberg. To fix these linter errors, WordPress-Docs needs to be enabled in Core as well.

There are Trac issues discussing the enabling of WordPress-Docs which you may want to check out:

1. https://core.trac.wordpress.org/ticket/41057
2. https://core.trac.wordpress.org/ticket/50744

[anton-vlasenko]

Before starting the code review, make sure that you have read the How section in the pull request description. This will make it easier to understand the proposed changes.

[hellofromtonya]

Core doesn't use the WordPress-Docs ruleset. For better parity, may want to consider removing this ruleset or at a minimum discussing why it's needed.

[jrfnl]

Core doesn't use it (yet) as the number of violations thrown was huge last time we checked, so a clean up is needed first.
I wouldn't consider that a reason not to use the ruleset here though. Better for new code to go in clean, don't you agree ?

[hellofromtonya]

I wouldn't consider that a reason not to use the ruleset here though. Better for new code to go in clean, don't you agree ?

Consider this scenario:

Code is changed in Core that then needs to be brought back to Gutenberg.

This happens a lot during release cycles. With Core not using this same ruleset, it can create scenarios where the code being brought back to Gutenberg does not pass the sniffs. When this happens, it can cause extra work to keep the code synchronized between Core and Gutenberg.

[jrfnl]

The Docs ruleset doesn't examine code, only documentation.

[hellofromtonya]

Hey @jrfnl,
Can you take a look at these comments, which are the source of why I first raised the question:

#48603 (comment)
#48603 (comment)

What do you think?

[jrfnl]

In both cases mentioned here, the docs in the GB repo are better and the docs in WP Core should be updated.

As Core isn't (yet) using the Docs ruleset, there is no reason why those updates should conflict with existing rules in WP Core.

[anton-vlasenko]

@jrfnl Yes, but WordPress-Docs causes linter errors when code gets backported from Core to Gutenberg, making it harder to keep both projects in sync (as the comment above showed).

Based on my understanding, WordPress-Docs could be temporarily disabled to make the backporting process simpler, and then re-enabled when Core supports it.

A decision needs to be made regarding whether the simplicity of backporting code takes precedence over enforcing the WordPress-Docs standard.

[hellofromtonya]

In both cases mentioned #48603 (comment), the docs in the GB repo are better and the docs in WP Core should be updated.

The docs may be better, but with this linting ruleset, they do not have parity with Core.

But without the ruleset in Core, how will contributors know Core's changes comply before porting the code back to Gutenberg? They won't. Thus it will cause more work and potentially further cause the code to be out-of-sync.

The goal of this PR is to achieve Core parity. Once Core introduces this ruleset, then Gutenberg can once again add it back into its workflow. But until then, this ruleset means Gutenberg and Core do not have parity and thus, more work is required as noted when porting Core changes to Gutenberg.

IMO this ruleset needs to be removed from Gutenberg to achieve Core parity.

[hellofromtonya]

Also noting, this ruleset needs to first be adopted in Core. Then it can be (re)adopted in Gutenberg.

[anton-vlasenko]

#56487

[anton-vlasenko]

I'm closing this PR in favor of #56487, with the intention of continuing the discussion on coding standards, specifically the WordPress-Docs ruleset, there.