Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 4 commits into from Dec 17, 2019

Conversation

@epiqueras
Copy link
Contributor

epiqueras commented Dec 6, 2019

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. .
…rver registered fixtures.
epiqueras added 2 commits Dec 6, 2019
@epiqueras epiqueras requested review from youknowriad and aduth Dec 6, 2019
@aduth
aduth approved these changes Dec 16, 2019
sources:
- ubuntu-toolchain-r-test
packages:
- libstdc++-4.9-dev

This comment has been minimized.

Copy link
@aduth

aduth Dec 16, 2019

Member

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Dec 17, 2019

Author Contributor

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

I added a comment.

( err ) => {
spinner.fail( err.message || err.err );
// eslint-disable-next-line no-console
console.error( `\n\n${ err.out || err.err }\n\n` );

This comment has been minimized.

Copy link
@aduth

aduth Dec 16, 2019

Member

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Dec 17, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@aduth

aduth Dec 17, 2019

Member

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Dec 17, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@aduth

aduth Dec 17, 2019

Member

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?

This comment has been minimized.

Copy link
@epiqueras

epiqueras Dec 17, 2019

Author Contributor

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

@epiqueras epiqueras merged commit 6a0a5f0 into master Dec 17, 2019
2 checks passed
2 checks passed
pull-request-automation
Details
Travis CI - Pull Request Build Passed
Details
@epiqueras epiqueras deleted the update/use-wp-env-in-more-places branch Dec 17, 2019
@aduth

This comment has been minimized.

Copy link
Member

aduth commented Dec 20, 2019

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

This comment has been minimized.

Copy link
Contributor Author

epiqueras commented Dec 20, 2019

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

This comment has been minimized.

Copy link
Member

aduth commented Dec 20, 2019

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

@epiqueras

This comment has been minimized.

Copy link
Contributor Author

epiqueras commented Dec 20, 2019

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.

@youknowriad youknowriad modified the milestones: Future, Gutenberg 7.2 Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.