Env: Support running arbitrary commands and use it for linting and server registered fixtures.

[epiqueras]

Follows: #17724

Description

This PR adds support to @wordpress/env for running arbitrary commands in one of the underlying docker containers. It also adds 2 containers that will be started on-demand for things like linting, generating fixtures, and PHP unit tests, composer and chriszarate/wordpress-phpunit. These are currently used to run npm run lint-php and npm run fixtures:server-registered.

How has this been tested?

It was verified that npm run lint-php and npm run fixtures:server-registered work as expected.

Types of Changes

New Feature: @wordpress/env now supports a run command for running arbitrary commands in one of the underlying Docker containers and also has 2 new containers, composer and chriszarate/wordpress-phpunit.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[aduth]

Can you explain what this is for? Is it possible to leave an inline comment with said explanation?

[epiqueras]

NodeGit breaks with the default C lib that Travis provides now.

I added a comment.

[aduth]

Should we prefer the stdout ? Seems like the error message might have more useful contents. Or both, even.

[epiqueras]

Shouldn't we send errors to stderr? To avoid unexpected outputs being piped to files and all that?

[aduth]

But if we're handling these errors, I would expect they're not going to be logged to stderr by default?

[epiqueras]

They're not, that's why I log them here.

[aduth]

They're not, that's why I log them here.

But if there's both stdout and stderr, with this implementation we'd only be logging the former and not the latter?

[epiqueras]

err.out and err.err are both error messages. It's just that some of the used libs format the error object thrown differently.

[aduth]

There are now very frequent Travis build errors due to the use of the custom libstdc package.

Example: https://travis-ci.com/WordPress/gutenberg/jobs/269314427

Installing APT Packages
0.04s$ sudo -E apt-get -yq --no-install-suggests --no-install-recommends $(travis_apt_get_options) install libstdc++-4.9-dev
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libstdc++-4.9-dev
E: Couldn't find any package by glob 'libstdc++-4.9-dev'
E: Couldn't find any package by regex 'libstdc++-4.9-dev'
apt-get.diagnostics
apt-get install failed
The command "sudo -E apt-get -yq --no-install-suggests --no-install-recommends $(travis_apt_get_options) install libstdc++-4.9-dev" failed and exited with 100 during .

Based on your previous comment at https://github.com/WordPress/gutenberg/pull/18986/files#r358740927 , it's not clear to me what exactly about NodeGit depends on this. Do you know if there is an alternative approach we could take here? Otherwise, I'd be inclined to suggest to revert this pull request to avoid the continued development disruption.

[epiqueras]

There are some alternatives in one of the original issues: nodegit/nodegit#853, like building NodeGit from source.

We can also try different Travis Linux distros.

[aduth]

How viable is it to abandon nodegit and run the native git command instead?

[epiqueras]

Viable, but not trivial.

We rely on it for showing download progress, dealing with all the different ref types, and falling back to different checkout strategies for them.