Env: Run tests using the same version used for development. #18703

epiqueras · 2019-11-23T00:41:46Z

Description

@wordpress/env's wp-env start command takes a [ref] positional argument, which defaults to master, to specify a version of https:/WordPress/WordPress to run. This was being respected for the development environment, but not for the tests environment, which resulted in E2E tests being ran on the default version shipped with the WordPress Docker container, i.e. not master with TwentyTwenty which our tests expect.

This PR addresses the issue by mounting an isolated copy of the checked out WordPress used for development, in the tests container, so that it can use the same version.

How has this been tested?

It was verified that after running wp-env start, both the development and tests containers are now running the same version of WordPress and all E2E tests pass as expected.

Types of Changes

Bug Fix: @wordpress/env now respects the specified WordPress version for both development and tests environments.

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 · 2019-11-27T05:09:21Z

packages/env/package.json

@@ -33,6 +33,7 @@
 },
 "dependencies": {
 "chalk": "^2.4.2",
+ "copy-dir": "^1.2.0",


We could potentially avoid pulling in a new dependency by reusing fs-extra (already a devDependencies in the root package.json), which is also promises-based (avoids need to promisify).

https:/jprichardson/node-fs-extra/blob/HEAD/docs/copy.md

I started that way, but opted to optimize for a leaner @wordpress/env. fs-extra is 10x bigger.

I started that way, but opted to optimize for a leaner @wordpress/env. fs-extra is 10x bigger.

That's fair. It's not as optimal for our project to have multiple dependencies capable of achieving the same goal, but good to be thinking about the consumer here. Might be a good reason to look to whether we should try to replace or remove our existing usage of fs-extra, which I know to be quite limited.

In fact, I think the only thing we really "need" it for is this directory removal:

gutenberg/bin/commander.js

Lines 246 to 247 in 598211e

await fs.remove( gitWorkingDirectoryPath );

await fs.remove( svnWorkingDirectoryPath );

Historically I might have used rimraf for this.

Apparently recursive is available as an experimental option now in the latest Node LTS, so we could consider that option as well: https://nodejs.org/dist/latest-v12.x/docs/api/fs.html#fs_fs_rmdir_path_options_callback

Historically I might have used rimraf for this.

And we already have rimraf. I'll make a note to replace it.

Apparently recursive is available as an experimental option now in the latest Node LTS, so we could consider that option as well

When it becomes stable right?

Apparently recursive is available as an experimental option now in the latest Node LTS, so we could consider that option as well

When it becomes stable right?

Ehh, it doesn't bother me much. Well.. assuming that it's experimental in the sense of "The API signature may change in the future" and not "Your entire filesystem might be destroyed".

Stability: 1 - Experimental. The feature is not subject to Semantic Versioning rules. Non-backward compatible changes or removal may occur in any future release. Use of the feature is not recommended in production environments.

aduth · 2019-11-27T05:12:22Z

packages/env/lib/env.js

+ * Promisified dependencies
+ */
+const copyDir = util.promisify( require( 'copy-dir' ) );
+const wait = util.promisify( setTimeout );


TIL setTimeout[ require( 'util' ).promisify.custom ] is a thing.

Yeah, I think it used to be that you had to use setTimeout[ require( 'util' ).promisify.custom ] directly.

aduth · 2019-11-27T05:16:26Z

packages/env/lib/create-docker-compose-config.js

 const commonVolumes = `
 ${ dependencyMappings }
 - ${ cwd }${ cwdTestsPath }/e2e-tests/mu-plugins/:/var/www/html/wp-content/mu-plugins/
 - ${ cwd }${ cwdTestsPath }/e2e-tests/plugins/:/var/www/html/wp-content/plugins/${ cwdName }-test-plugins/`;
 const volumes = `
 - ${ cwd }/../${ cwdName }-wordpress/:/var/www/html/${ commonVolumes }`;
 const testsVolumes = `
- - tests-wordpress:/var/www/html/${ commonVolumes }`;
+ - ${ cwd }/../${ cwdName }-tests-wordpress/:/var/www/html/${ commonVolumes }`;


I know it exists already for gutenberg-wordpress, but this directory creation one level up from the project root was very unexpected for me the first time I encountered it. Was there a reason to not include it as a directory within the project, like already exists with wordpress? For one thing, it makes future clean-up easier, since it's kept self-contained.

It would make the plugin volume recursive and sometimes Docker tripped up on that for some reason.

aduth · 2019-11-27T05:24:53Z

packages/env/lib/env.js

@@ -97,6 +103,31 @@ module.exports = {
 // Some commit refs need to be set as detached.
 await repo.setHeadDetached( ref );
 }
+
+ // Duplicate repo for the tests container.
+ let stashed = true; // Stash to avoid copying config changes.


I wonder if, rather than this stash + filesystem copy, we could just create a clone from the repoPath.

In some brief testing in the Terminal, when I'm in gutenberg-wordpress, then run:

git clone . ../gutenberg-tests-wordpress/

... it creates a checkout of WordPress, at the same commit as in gutenberg-wordpress, excluding modifications in the working directory. Isn't this the same as what you're trying to achieve with the logic here?

I don't think it copies over things like a detached head ref from await repo.setHeadDetached( ref );.

epiqueras added [Type] Bug An existing feature does not function as intended [Type] Build Tooling Issues or PRs related to build tooling [Package] Env /packages/env labels Nov 23, 2019

epiqueras added this to the Future milestone Nov 23, 2019

epiqueras self-assigned this Nov 23, 2019

epiqueras requested review from noahtallen and a team November 23, 2019 00:41

aduth reviewed Nov 27, 2019

View reviewed changes

epiqueras mentioned this pull request Nov 27, 2019

Package: Replace fs-extra with rimraf. #18790

Merged

youknowriad approved these changes Dec 6, 2019

View reviewed changes

epiqueras added 2 commits December 6, 2019 10:31

Env: Run tests using the same version used for development.

2626736

Env: Stash before repo duplication to avoid copying config changes.

e8a2b5e

epiqueras force-pushed the try/using-the-same-wp-version-for-dev-and-tests-envs branch from 411e3e8 to e8a2b5e Compare December 6, 2019 18:32

epiqueras merged commit 325e4e6 into master Dec 6, 2019

epiqueras deleted the try/using-the-same-wp-version-for-dev-and-tests-envs branch December 6, 2019 19:08

youknowriad modified the milestones: Future, Gutenberg 7.1 Dec 9, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Env: Run tests using the same version used for development. #18703

Env: Run tests using the same version used for development. #18703

epiqueras commented Nov 23, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

epiqueras Nov 27, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

aduth Nov 27, 2019

epiqueras Nov 27, 2019

	await fs.remove( gitWorkingDirectoryPath );
	await fs.remove( svnWorkingDirectoryPath );

Env: Run tests using the same version used for development. #18703

Env: Run tests using the same version used for development. #18703

Conversation

epiqueras commented Nov 23, 2019

Description

How has this been tested?

Types of Changes

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment