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

PoC: Run E2E tests with WP Playground #62692

Draft
wants to merge 30 commits into
base: trunk
Choose a base branch
from

Conversation

WunderBart
Copy link
Member

@WunderBart WunderBart commented Jun 20, 2024

What?

A simple PoC for running E2E tests against a Playground instance (instead of wp-env).

How?

  1. Checkout this branch.
  2. Run npm install && npx playwright install to install deps.
  3. Run npm run build to build Gutenberg.
  4. Run node playground-server.js to start the test env via Playground.
  5. Run the tests with WP_BASE_URL=http://127.0.0.1:9400/ npm run test:e2e.
@WunderBart WunderBart force-pushed the try/run-e2e-tests-against-playground branch 2 times, most recently from 26f785c to f60c136 Compare June 20, 2024 13:38
@WunderBart WunderBart force-pushed the try/run-e2e-tests-against-playground branch from f60c136 to 5416734 Compare June 20, 2024 13:59
@WunderBart WunderBart changed the title PoC: Run E2E tests against WP Playground Jun 20, 2024
@WunderBart
Copy link
Member Author

@adamziel, many tests are failing because the database randomly disconnects, causing the app to throw 500 errors. I have yet to find a consistent way to reproduce the issue, but I'll continue working on it when I'm back (around July 2nd). Once this issue is resolved, the legit failures will provide valuable information on Playground's current limitations compared to wp-env.

It's been nice to see how easy it is to circumvent wp-env. Spinning up the WP Playground instance is really fast, too. 💪

cc: @griffbrad @dmsnell

@swissspidy
Copy link
Member

FWIW for https://github.com/swissspidy/media-experiments I always use wp-now for running tests locally (as I can't use Docker) and I constantly run into the same issue with 500 errors. Curious to hear what you find out.

@dmsnell
Copy link
Member

dmsnell commented Jul 2, 2024

@WunderBart @swissspidy are you using a MySQL connection or relying on SQLite when you get the 500s? How do we know it's a database disconnect? I didn't think that is possible with SQLite, and I wonder also if we're seeing concurrency issues with multiple requests? Mostly the Playground handles requests serially, but I think it should be fine with concurrent requests as well.

@swissspidy
Copy link
Member

Hmm I don't think it's a database issue in my case. Also no idea how to make it use MySQL, so I think it's just the default SQLite setup.

Just did another test and it's actually more a timeout than a proper error 500.

The server stops responding and in the terminal I get errors like this:

Error: PHP.run() failed with exit code 255 and the following output: 
    at _NodePHP.run (/Users/pascalb/Workspace/WordPress/media-experiments/node_modules/@php-wasm/node/index.cjs:72937:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async #dispatchToPHP (/Users/pascalb/Workspace/WordPress/media-experiments/node_modules/@php-wasm/node/index.cjs:72470:14)
    at async PHPRequestHandler.request (/Users/pascalb/Workspace/WordPress/media-experiments/node_modules/@php-wasm/node/index.cjs:72385:14)
    at async PHPBrowser.request (/Users/pascalb/Workspace/WordPress/media-experiments/node_modules/@php-wasm/node/index.cjs:72170:22)
    at async file:///Users/pascalb/Workspace/WordPress/media-experiments/node_modules/@wp-now/wp-now/main.js:945:20 {
  output: {
    stdout: '<!DOCTYPE html>\n' +
      '<html lang="en-US">\n' +
      '<head>\n' +
      '\t<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\n' +
      '\t<meta name="viewport" content="width=device-width">\n' +
      '\t\t',
    stderr: ''
  },
  source: 'request'
}

But I don't wanna hijack the discussion here :-)

Copy link

github-actions bot commented Jul 11, 2024

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
  • Labels found: Needs Author's Reply.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

@WunderBart WunderBart force-pushed the try/run-e2e-tests-against-playground branch from 890ed10 to df7d403 Compare October 3, 2024 14:48
@WunderBart WunderBart force-pushed the try/run-e2e-tests-against-playground branch from bbc4e3a to 5603487 Compare October 3, 2024 16:48
@WunderBart WunderBart force-pushed the try/run-e2e-tests-against-playground branch from 5603487 to 1e0155b Compare October 3, 2024 17:50
@WunderBart
Copy link
Member Author

WunderBart commented Oct 6, 2024

@WunderBart @swissspidy are you using a MySQL connection or relying on SQLite when you get the 500s? How do we know it's a database disconnect? I didn't think that is possible with SQLite, and I wonder also if we're seeing concurrency issues with multiple requests? Mostly the Playground handles requests serially, but I think it should be fine with concurrent requests as well.

The db disconnected is what's being thrown every time that 500 happens:

test-failed-1

@dmsnell @swissspidy @adamziel, I'm pretty sure it's a Playground memory leak / CI resources issue. It's not tied to any tests specifically and to any specific Playwright action (although Playwright might also be leaking 🤷). To confirm that, I tried running a smaller number of tests per job, and the ones that the suites usually fail at pass if run in smaller batches. For example, here are three iterations, each running more tests from the previous one, finally (consistently) failing at iteration 3:

  1. From https://github.com/WordPress/gutenberg/actions/runs/11203311740/job/31140414656

    Screenshot 2024-10-06 at 11 52 04
  2. From https://github.com/WordPress/gutenberg/actions/runs/11203401738/job/31140608683

    Screenshot 2024-10-06 at 11 52 27
  3. From https://github.com/WordPress/gutenberg/actions/runs/11203469006/job/31140757736

    Screenshot 2024-10-06 at 11 52 56

FWIW, I did observe the server logs and they weren't any helpful. All the requests end with 200 until suddenly it's 500.

It also seems to be related to what we're experiencing in Woo where we're running with wp-env, which suggests it might be a Playwright/PHP memory issue (?): woocommerce/woocommerce#51658 (comment)

I'm kinda out of ideas on how to debug this further, also because I need a break from this issue. 😅 Any help here would be much appreciated! 🙏

@adamziel
Copy link
Contributor

adamziel commented Oct 7, 2024

@wojtekn does that happen at all in Studio?

@adamziel
Copy link
Contributor

adamziel commented Oct 7, 2024

@WunderBart wonderful explorations, thank you! Let's extract as much debug information as we can. A few ideas:

  • Enabling all the debugging constants
  • Upload Playwright trace with, hopefully, some specific PHP errors on the screen
  • Upload WordPress debug.log as an artifact
  • Upload the WordPress directory as an artifact – hopefully the failure would still be reproducible after downloading it

Also, are you running @wp-playground/cli/wp-now? If yes, and we're indeed dealing with some sort of memory leak, you could kill and restart the server and then re-run the test. However, if you're running the browser version of Playground, there isn't anything similar we could do.

Also let's link this with this related issue: WordPress/wordpress-playground#1596

@wojtekn
Copy link
Contributor

wojtekn commented Oct 8, 2024

@wojtekn does that happen at all in Studio?

@adamziel No, I didn't spot such an issue in Studio.

@WunderBart
Copy link
Member Author

WunderBart commented Oct 8, 2024

Thanks for the feedback, @adamziel!

@WunderBart wonderful explorations, thank you! Let's extract as much debug information as we can. A few ideas:

  • Enabling all the debugging constants
  • Upload Playwright trace with, hopefully, some specific PHP errors on the screen
  • Upload WordPress debug.log as an artifact
  • Upload the WordPress directory as an artifact – hopefully the failure would still be reproducible after downloading it

Also, are you running @wp-playground/cli/wp-now? If yes, and we're indeed dealing with some sort of memory leak, you could kill and restart the server and then re-run the test. However, if you're running the browser version of Playground, there isn't anything similar we could do.

I'm running with @wp-playground/cli server. I thought about making a custom retry mechanism for restarting the server, but I believe it's more important here to fix the 500 issue so we can safely run any number of tests with a vanilla setup.

An example trace.zip isn't really that helpful - it just shows that the test fails at navigation or plugin activation because of the 500:

Screenshot 2024-10-08 at 09 11 18

The server logs around the 500 aren't that helpful either. Everything is peachy until a sudden 500 is thrown (tried with different PHP versions FWIW). Here's a snippet from around the error line:

172.18.0.1 - - [06/Oct/2024:14:53:36 +0000] "GET /wp-json/wc/store/v1/cart?_locale=user HTTP/1.1" 200 2093 "http://localhost:8889/wp-admin/site-editor.php?postId=woocommerce%2Fwoocommerce%2F%2Forder-confirmation&postType=wp_template&canvas=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.18 Safari/537.36"
172.18.0.1 - - [06/Oct/2024:14:53:37 +0000] "POST /wp-json/wp/v2/users/me?_locale=user HTTP/1.1" 200 5539 "http://localhost:8889/wp-admin/site-editor.php?postId=woocommerce%2Fwoocommerce%2F%2Forder-confirmation&postType=wp_template&canvas=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.18 Safari/537.36"
172.18.0.1 - - [06/Oct/2024:14:53:37 +0000] "PUT /wp-json/wp/v2/plugins/woocommerce-blocks-test-plugins/register-product-collection HTTP/1.1" 500 438 "-" "Playwright/1.46.1 (x64; ubuntu 20.04) node/20.17 CI/1"
127.0.0.1 - - [06/Oct/2024:14:53:38 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.54 (Debian) PHP/7.4.33 (internal dummy connection)"
172.18.0.1 - - [06/Oct/2024:14:53:38 +0000] "GET /wp-json/wp/v2/plugins HTTP/1.1" 500 2719 "-" "Playwright/1.46.1 (x64; ubuntu 20.04) node/20.17 CI/1"
127.0.0.1 - - [06/Oct/2024:14:53:39 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.54 (Debian) PHP/7.4.33 (internal dummy connection)"
172.18.0.1 - - [06/Oct/2024:14:53:39 +0000] "GET /wp-json/wp/v2/plugins HTTP/1.1" 500 2719 "-" "Playwright/1.46.1 (x64; ubuntu 20.04) node/20.17 CI/1"
172.18.0.1 - - [06/Oct/2024:14:53:39 +0000] "GET /wp-json/wp/v2/plugins HTTP/1.1" 500 2719 "-" "Playwright/1.46.1 (x64; ubuntu 20.04) 

Maybe I'm just missing something obvious there, though! 🤞

Do we have any DB experts in this context who could help inspect the issue from that side? 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment