docker: Add a --php option to jetpack docker phpunit

[anomiex]

Fixes #32914

Proposed changes:

To make it easier to run tests locally with a specified version of PHP.

This turns out to be a bit more complex than it sounds, as we need to be able to install the necessary version of PHP inside the container and we need to make sure the correct versions of Composer deps (particularly phpunit) are installed too. And then use those rather than whatever is in the monorepo install.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

#32914
#32929 (comment)

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Temporarily change

  jetpack/tools/docker/docker-compose.yml

  Line 37 in 197ba02

  image: automattic/jetpack-wordpress-dev:latest

  to refer to ghcr.io/automattic/jetpack-wordpress-dev:pr-32979 and restart your docker env (jetpack docker stop && jetpack docker up -d).
• Then try jetpack docker phpunit --php=7.0, or jetpack docker phpunit-crm --php=7.2

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta > Jetpack and enable the try/docker-jetpack-phpunit-php-version branch.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack try/docker-jetpack-phpunit-php-version
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team Review" label and ask someone from your team review the code. Once reviewed, it can then be merged.
If you need an extra review from someone familiar with the codebase, you can update the labels from "[Status] Needs Team Review" to "[Status] Needs Review", and in that case Jetpack Approvers will do a final review of your PR.

---

Jetpack plugin:

• Next scheduled release: October 10, 2023.
• Scheduled code freeze: October 9, 2023.

[ice9js]

Overall, I'd say this looks solid for a first pass and would already be a huge improvement. In terms of fine tuning it, I see two opportunities, but we can work on those in separate PRs:

• How about only displaying the headers for PHP/Composer install unless -v/verbose mode is set, to make things a tiny bit cleaner? I'm also ok if we don't do this, since you'd only have to go through it once per container.
• Can we rely on PHPUnit's PHAR releases instead of having it as a composer dependency? I mean, I wouldn't mind keeping the latest in composer and having PHARs for the older versions but my concern is that'd create a conflict with the autoloader. The goal here would be to eliminate the need to mess with dependencies/composer for unit testing altogether.

Let me know what you think and I think we can start working on getting it merged :)

[anomiex]

• How about only displaying the headers for PHP/Composer install unless -v/verbose mode is set, to make things a tiny bit cleaner? I'm also ok if we don't do this, since you'd only have to go through it once per container.

That could turn out to be confusing, as phpunit also has a -v option.

• Can we rely on PHPUnit's PHAR releases instead of having it as a composer dependency? I mean, I wouldn't mind keeping the latest in composer and having PHARs for the older versions but my concern is that'd create a conflict with the autoloader. The goal here would be to eliminate the need to mess with dependencies/composer for unit testing altogether.

If PHPUnit were the only thing, probably. Although it would be more complex as we'd need to figure out the appropriate PHPUnit version to download from the PHP version instead of letting Composer handle it.

But for Jetpack we also need to get an appropriate version of johnkary/phpunit-speedtrap, and at some point for CRM we might need to get an appropriate version of the codeception packages they use, etc.

And we also need to not break when the lock file contains too-new versions of changelogger's symfony deps even though they're almost certainly not used during the tests.

[ice9js]

As we already talked about, this seems to be installing dependencies separately for each PHP version so while we can't skip composer install, at least it should mess up the project dependencies too much once you're done testing.

Let's get this out :)