[wp-trac] [WordPress Trac] #47767: Simplify and backport the local environment

[WordPress Trac]

#47767: Simplify and backport the local environment
-------------------------------------+-----------------------
 Reporter:  pento                    |       Owner:  pento
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  5.3
Component:  Build/Test Tools         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:
-------------------------------------+-----------------------

Comment (by pento):

 Thanks for testing, @noisysocks!

 Replying to [comment:26 noisysocks]:
 > This is looking good!
 >
 > I received this error when running `npm run env:reset` with the
 containers running:
 >
 > {{{
 > ERROR: Failed to remove image for service mysql: 409 Client Error:
 Conflict ("conflict: unable to remove repository reference "mysql:5.7"
 (must force) - container 015b4262f1c1 is using its referenced image
 f6509bac4980")
 > }}}

 Are you running the Gutenberg local-env, too? If that's running, it won't
 be able to delete the MySQL image that's in use.

 > - I still am wishing `npm run dev` ran `grunt watch --dev`. I understand
 the desire for consistency between `npm` and `grunt`, though.

 I agree, I've changed it in [attachment:"47767.11.diff"]. This was only
 added when the e2e env landed, it's not a problem to change it.

 > - I mistakenly thought that `npm run env:reset-site` was a command that
 could be run, when it's actually an internal command used by `npm run
 env:install`. Not sure if a different name (e.g. `env:install-reset`)
 would help with this.

 Fair point, [attachment:"47767.11.diff"] prefixes the internal commands
 with `__`, which makes them a little more obviously not for external use.

 > Ideally we'd only have commands that the user is supposed to run in
 `"scripts"`.

 Agreed, and I'm fine with iterating on how this all works after we get it
 committed to `trunk`.

 > - It's awkward that `npm run test:php`, on first run, gives you an error
 about a missing `wp-tests-config.php` file with no clues on how to set one
 up using the built-in MySQL container.

 Good catch! I don't think we have a simple method for generating `wp-
 tests-config.php`, the method in `.travis.yml` is ugly and not cross-
 platform compatible. A small script to generate the file might be an
 option.

 > - I received 'connection refused' errors when testing with PHP 5.3 and
 5.4, and a WordPress error when using PHP 5.5.

 For the 'connection refused' errors, it seems like nginx is redirecting to
 port 80 for requests that don't end in a `/`. That'll require further
 investigation.

 > - It would be neat if `LOCAL_PHP=7.4-fpm` worked so that we could test
 against the upcoming PHP release.

 Yah, I thought about that (also for the nightly build), but decided to
 leave it for later, as it would also need a job to regenerate the build
 regularly.

 > - I wasn't able to access WP Admin with MySQL set to use anything
 earlier than 5.6.

 MySQL 5.6 is currently the oldest version with
 [https://hub.docker.com/_/mysql/ official builds]. We'll need to provide
 our own for older versions.

 > - How does one access the nginx error log? It might be useful to
 document this in e.g. a handbook page for this tool.

 [attachment:"47767.11.diff"] adds a `npm run env:logs` command.

 > - The `README` is a nice addition, but I wonder if it goes into too much
 detail?

 Yah, I agree. I've trimmed it down for now, we can add a link to the
 handbook later, once that handbook page exists.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47767#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform