Allow E2E testing with Release Candidates

[mikkamp]

Changes proposed in this Pull Request:

As a followup to PR #2041 this PR makes it easier to install Release Candidate versions of both WordPress and WooCommerce. The documentation has been updated to describe how the tests can be run with different versions of WordPress and WooCommerce.

Additionally several selectors in the test were updated as WooCommerce 8.0 introduces blocks for the standard checkout.

I also added workflow inputs to allow the E2E workflow to be run with release candidate versions of WP and/or WC. I ran the test successfully here with WP 6.3-RC3 and WC 8.0.0-rc.1.

Detailed test instructions:

1. Checkout this PR and install packages: nvm use && npm ci
2. Start the wp-env environment: npm run wp-env:up (if you previously had this running you might need to run npm run wp-env destroy)
3. Install the Chromium browser for Playwright: npx playwright install chromium
4. Update to WP RC:

npm run -- wp-env run tests-cli -- wp core update --version=6.3-RC3
npm run -- wp-env run tests-cli -- wp core update-db

5. Update to WC RC:

npm run -- wp-env run tests-cli -- wp plugin update woocommerce --version=8.0.0-rc.1
npm run -- wp-env run tests-cli -- wp wc update

6. Start the E2E tests: npm run test:e2e
7. Confirm that all the tests pass

Changelog entry

• Dev - Allow E2E testing with Release Candidates.

[martynmjones]

Hey @mikkamp, thanks for adding an easy way to test with RCs.

Tested the branch locally and getting environments with specific versions set up and running tests against them is easy and works well.

Although not related directly to the changes here (I think) I am getting a test failure.

It looks like the endpoint being called isn't available as the test-data.php plugin gets deactivated due to an invalid header.

All others tests are passing though and no issues settings release candidates so LGTM ✅

[mikkamp]

It looks like the endpoint being called isn't available as the test-data.php plugin gets deactivated due to an invalid header.

Interesting error, I'm not able to replicate that and it's the first time I come across it. From a quick search on Google I see mentions of this happening when the plugin is activated too quick after installing, activating it a second time usually works. Do you still get that error after trying again?

One thing we could try is add a mapping in wp-env and then activate it in the install script (which is what WC does with a custom plugin). Should I add a commit for that change, or is that something you can test locally (since I'm not getting the same error here)?
I'd also recommend to run npm run wp:env destroy to start with a completely clean wp-env site.