Framework: Fix server-registered fixtures script

[aduth]

This pull request seeks to resolve an issue where npm run fixtures-regenerate was not working.

There were a few contributing factors:

• As of Env: Support running arbitrary commands and use it for linting and server registered fixtures. #18986, the get-server-blocks.php script was run in the tests-wordpress-phpunit Docker image which, unlike previously, was not a WordPress installation folder structure expected by the script, where the script assumes either to be provided with an ABSPATH WordPress install path, or be able to reach out of its own plugin directory several levels up to the closest WordPress install.
• At least for me, while I might have expected that redirecting output within the Docker container would be reflected back into the host volume, this was not the case (server-registered.json). The script was changed so the output of the NPM script itself was redirected.
  • This required:
    • Running wp-env run directly, as otherwise npm run wp-env run would include undesirable extra redirected output
    • Changing/fixing wp-env run to avoid formatting output when piping/redirecting

Testing instructions:

Verify server-registered fixtures generation works as expected:

1. Remove existing file: rm test/integration/full-content/server-registered.json
2. Run npm run fixtures-regenerate
3. Note working directory is clean (regenerated without changes): git status

[epiqueras]

There were a few contributing factors:

These make me think the volume was not mounted correctly. Especially the second one. Also, this was working last week, strange. It's probably related to how the plugin sometimes unmounts.

[gziolo]

Does it mean you need to have wp-env configured to run this script and wp-scripts env in some other places?

[epiqueras]

No, only wp-env is used here.

[aduth]

Running it this way is essentially identical as what would happen before, since npm run wp-env does the same thing, but because of the output redirecting, and the way that running NPM scripts would generate some (unwanted) output if we were to run it through npm run wp-env, it was changed to this.

[aduth]

Why would this PR change this file? We had a stale version of this on master, but the tests still passed? So not updating this file doesn't break the tests as long as you keep the old fixtures even if the block implementation has changed in some ways?

I believe that's an accurate assessment, yes. It would be good to improve this, perhaps one of either:

• Generate the fixtures on-demand as part of the test run
• Consider this as an "artifact" so the Build artifacts job would run the script and check for changes
  • Conflicts with goal of Build Tooling: Reevaluate "Build Artifacts" NPM install script #16157

[aduth]

Out of curiosity, I pretty-printed the "before" and "after" to see what the specific differences are:

https://www.diffchecker.com/Ncn1BpQO

Most of these are sensible, but I do note that it removed the shortcode block, likely related to the changes in #19534. Generally, if these tests are worth keeping around, we'll probably need to enhance them to take account of block.json registration.

[epiqueras]

Consider this as an "artifact" so the Build artifacts job would run the script and check for changes

This option makes sense and is cheaper.

Conflicts with goal of #16157

Even if npm ci is fixed. I think documentation artifact checking is useful.

Generally, if these tests are worth keeping around, we'll probably need to enhance them to take account of block.json registration.

Yes