Dev setup updates – spring 2018 #1329
Conversation
In the frontend `build` script, I had to use `node_modules/.bin/tsc` instead of just `tsc`. Maybe it's a bug in npm@6, it was working fine before.
- Some Docker images were no longer building, for example, newer Xdebug no longer supports PHP 5.x. I've updated all of them to use PHP 7.2. - New `npm run rebuild-images` script. - `Dev-Setup.md` updated slightly. - Test database runs on a standard port 3306, I'm not sure how the 3391 port could have worked previously (`test-config.yml` does not support a port) Some e2e tests are currently failing which needs further exploration.
borekb
added
the
scope: dev-infrastructure
|
Current status:
@pavelevap could you please try it on your computer and generally go through the |
frontend/package.json
Outdated
| "scripts": { | ||
| "start": "node webpack/webpack-dev-server.js --config webpack/webpack.dev.js --env.port 8888", | ||
| "build": "npm install && tsc --noEmit && webpack -p --config webpack/webpack.prod.js --hide-modules", | ||
| "build": "npm install && node_modules/.bin/tsc --noEmit && node_modules/.bin/webpack -p --config webpack/webpack.prod.js --hide-modules", |
There was a problem hiding this comment.
This change does not work for me with cmd.exe.
|
@borekb about how soon do you think this’ll be approved and merged? exciting stuff! |
|
@leepeterson The tests are currently failing and the updated Dockerfiles are not entirely finished yet. @pavelevap is looking at it, I personally won't have much time to return to it until next week. |
…ld be unified, images pushed to Docker Hub and maybe Docker stacks / Swarm mode used. This is the first step in which the dev-env image has been moved to its own `./dev-env/wordpress-image` folder and no longer installs WordPress automatically (this anticipates that tests will use this image as well). The image is now also pushed to Docker Hub as `versionpress/wordpress`. It is close to the stock WordPress image, just with Git, WP-CLI and Xdebug installed.
…y, however, one-off jobs (we'll need them for tests) are not really supported, see moby/moby#23880, so this will get reverted soon.
This reverts commit 48ff634.
- Both use cases run from the same `docker-compose.yml`. Docker-compose always runs a specific service from the stack, e.g., `docker-compose up -d wordpress`, never the entire `docker-compose up` which would also run the tests (we want that on demand). - There are two test "services" in `docker-compose.yml`: `tests` which doesn't start WordPress and `tests-with-wordpress` which does. When running tests, a decision needs to be made which one to run. - To make running tests simpler, there are two new npm scripts, `npm run tests:unit` and `npm run tests:full`. There is no `tests` script for now, one needs to decide which tests to run. - `testenv` image and the entire `package.json` project in `plugins/versionpress/tests` is no longer needed so I've removed them. - Docker Compose stack is run in background by default. Dev-Setup.md updated to give tips how to work with the background scenario. - `npm run cleanup-docker-stack` was not a great name, there are now two separate scripts `stop` and `stop-and-cleanup` that hopefully make the distinction clearer. - Containerized MySQL now runs on port 3306 (ports will need revising later on). - Some cleanups of `docker-compose.yml`, e.g., `depends_on` removed (links are used). - Other Dev-Setup.md cleanups. Note that the 'tests:full' tests are still failing, fixes are coming in later commits.
|
✨ I've significantly updated our devenv / testing stack in 06e1965. See the commit's full description for all the details but the TL;DR is that we now use a unified Docker Compose stack for both devenv and testing purposes and the original The integration tests are still failing but at least there is now a predictable environment where to hunt bugs down. |
…nning tests under the www-data user always (no sudo). This is done a bit indirectly as Docker doesn't support mounting volumes as a non-root user (see moby/moby#2259), by creating a custom image `versionpress/wordpress:cli`. Newer Git version was necessary to install into the container anyway.
|
Killed the permission bugs in 87769bf! 🎉 Many more tests pass now:
|
…ndows tips given.
…replace Gulp. It breaks down with more complex stuff like packaging a release.
…r in more complex cases, via TypeScript files in the `./scripts` directory. Why the change? Gulp used to be popular (and progressive!) when we first started with VersionPress but today, it feels like an unnecessary abstraction. In our specific case, it was probably causing strange issues with nested `npm run`s – hard to tell as some dependencies were a couple of years old / unmaintained. Also, in the past, we've had trouble generating ZIP files reliably and Gulp itself doesn't seem to be that actively developed anyway. So I rewrote the functionality to a simpler and more straightforward code. Less dependencies = win.
…ntroduced in 0cf52f0 (was probably some temporary problem on my PC)
…will need separate effort to get fixed.
|
Status update: db6842c adds support for command-line started debugging. That will be quite important for me as I cannot get PhpStorm to work correctly with Docker Compose (IDEA-192416). All tests are passing for me when I launch them in smaller batches. The full returned like 150 concurrent connections. |
…ections" when running the full test suite
|
a104f51 fixes "too many connections" database error, making the
The remaining errors are in workflow tests (cloning / merging) which will need a slight update of the filesystem structure in our Docker Compose stack. Errors are: |
- The test site moved into a subdirectory of /var/www/html – it is in `/var/ww/html/wptest`, the clone in `.../wptestclone`. - Updated CloneMergeTest so that it runs correctly Note: `CloneMergeTest::dateModifiedMergesAutomatically()` test currently fails but it's a problem with the merge driver, most likely, not with the testing setup itself.
|
2a477de makes Workflow tests run again. Merge driver test is still failing because it seems that the merge driver doesn't select the newer datetime – might be an actual bug in it. This is an example output: (The newer date is expected but |
…rrect place, not `/var/www/html` (it wasn't causing any major trouble but was unnecessary)
|
🎉 WP-CLI tests now fully now! The only failures are merge driver tests as described in #1329 (comment) which will be for a separate PR.
Remaining TODO items in this PR:
|
|
I've updated the PR description and consider this PR mostly done. @JanVoracek verified that the tests run exactly the same on Mac which is good. If someone wants to look at Dev-Setup.md at this point and possibly try the dev / test setup, that would be great. I think we'll be able to merge next week. |
pavelevap
left a comment
pavelevap
left a comment
There was a problem hiding this comment.
Tests are working, huge improvements, I guess. 🎉 Some minor things can be solved in particular issues.
|
Thanks, @pavelevap, I think we can merge this. |
borekb
added
the
noteworthy
Our dockerized dev setup, originally built in #1227, was not working for me, for example, the newest Xdebug is no longer compatible with PHP 5.x. When fixing this, I've encountered several other issues with our dev / test setup so this PR ends up being a pretty major update.
Highlights
docker-compose.yml, using the same images for both scenarios.Dev-Setup.mdhas been reviewed and updated.Noted for future work
facebook/webdriverseems to be more popular thangiorgiosironi/phpunit-selenium(Selenium2TestCase), I've also heard good things about Codeception. As long-term maintainability of our Selenium tests is an important goal, considering a new framework is something we should do.test-config.ymlis a legacy concept, for example, a test suite should define tests for both WP-CLI and Selenium workers, or for multiple versions of WordPress. Picking test suites fromphpunit.xmlshould be enough.Full todo list
versionpress/wordpressnpm run build-imagesandnpm run push-imagesscripts (eed0177, 7fa6847)cleanup-docker-stackwithnpm stopandnpm run stop-and-cleanup.phpunit.override.xmlis not a great name, it's not overriding anything. Gitignorephpunit.*.xmland update docs.home/siteurl. So both web servers and DB servers run on their default ports 80 and 3306. See 920e8fb.Test withcmd.execmd.exewas close to working again but it will just be easier to require Git Bash (curl,rm -rfetc.). It is automated since 9e0904e.copyVersionPressFiles(), maybe related to Docker Toolbox? Explore this.--colorfrompackage.jsontophpunit.xml(This is an issue-less PR.)