Adding a docker-based dev env

[kraftbj]

Testing moving development commands to within docker to avoid local variances or require specific versions of things to be installed locally.

Proposed changes:

• Adds a new js-package for a new jetpack cli.
• Adds a docker setup for a new dev env.

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

None yet.

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

No.

Testing instructions:

Testing the new CLI

• Ensure you have Docker Desktop (Mac, if applicable), git, and node installed.
• On Mac, it seems you have to go to the Docker Desktop settings->Resources->Proxy->check "Manual Proxy Configuation" [otherwise the wordpress container can't reach wordpress.org, haven't dug into that]. Restart Docker if applicable.
• npm i -g @automattic/jetpack-cli
• cd /tmp (or somewhere else without Jetpack)
• jp -v (confirm it is installed, 1.0.0-beta1 is the current version)
• jp --help -- it should report it can't find a monorepo checkout and invite you to use jp init
• jp init -- follow prompts
• cd jetpack (or whatever dir)
• git checkout try/dev-in-docker to get on this branch.
• jp --help -- this should pull the new dev container (I manually pushed it to docker hub for the sake of testing)
• jp build plugins/jetpack --with-deps (does it work?)
• jp docker up -d -- the CLI output will not be the expected "visit localhost". it'll say it's done before it's ready (need to fix).
• Visit localhost ensure it is the WP install.
• jp docker install -- should run the usual install process, localhost should show a regular site.
• jp docker down

Testing the existing setup.

• In a working dev environment, e.g. jetpack commands work.
• Do nothing else.
• Run jetpack --help, jetpack build plugins/jetpack --with-deps
• Run jetpack docker up -d
• etc
• NOTE: You can switch to the new CLI in your existing checkout if you delete the node_modules dir. If you want to go back and forth between the two, you'll need to nuke the node_modules each time you switch.
  Does everything still work as expected? If not, does clearing the docker containers/images resolve it? Please note that.

The intent of the PR as this point is create a new, rough, beta way to dev within docker without impacting the existing jetpack commands running locally for devs who have things working. I hope to quickly iterate to the dev-in-docker is a reliable way for anyone to jump into, but the local way of doing it should still work too (and for the foreseeable future).

Known issue: Git Hooks do not work on a fresh install using only jp for dev. It'll commit, push, etc without running the hooks.

[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, select your plugin, and enable the try/dev-in-docker branch.

  • For jetpack-mu-wpcom changes, also add define( 'JETPACK_MU_WPCOM_LOAD_VIA_BETA_PLUGIN', true ); to your wp-config.php file.

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

  bin/jetpack-downloader test jetpack try/dev-in-docker
  

  bin/jetpack-downloader test jetpack-mu-wpcom-plugin try/dev-in-docker
  

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 a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ 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.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

[jeherve]

I wanted to test this from a fresh computer, so I tried to start from a computer running Ubuntu, where nothing was installed yet.

Unfortunately, I run into an error when I run BUILD_LOCAL=1 jp build plugins/jetpack --with-deps:

ERROR: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Head "http://%2Fvar%2Frun%2Fdocker.sock/_ping": dial unix /var/run/docker.sock: connect: permission denied

I'm not sure what's causing this, and I'm not familiar enough with Ubuntu to debug this I'm afraid.

[anomiex]

Gave it a quick once-over.

[anomiex]

This will work for most people, so maybe it's fine, but I do note it will blow up if something else is already running on localhost port 80.

[kraftbj]

nod, I believe this is the same as the existing jetpack docker, except the existing command accepts an optional port arg

[anomiex]

More importantly, the existing command allows overriding the default via tools/docker/.env, while your code here overrides tools/docker/.env.

[kraftbj]

Ahh, you're totally right. The .env should now work after 5e8d778

[anomiex]

This breaks normal use of jetpack docker up.

$ jetpack docker up -d
WARNING: The HOST_CWD variable is not set. Defaulting to a blank string.
ERROR: build path /tools/docker either does not exist, is not accessible, or is not a valid URL.
Command exited with status 1

[kraftbj]

I believe this should work now after e098e69

[anomiex]

$ jetpack docker up
ERROR: build path /usr/local/src/automattic/jetpack/tools/docker/tools/docker either does not exist, is not accessible, or is not a valid URL.
Command exited with status 1

Fixing that will, for me, likely still run into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087370. Although we probably don't need to consider me personally as a blocker.

But even for everyone else that it does work for, it'll mean that jetpack docker up will unnecessarily build that image to start an instance of the container which will then immediately exit.

[kraftbj]

nod, thanks. I'll dig into it more than the quick-looking fix.

[kraftbj]

In addition to testing on my two production Apple Silicon (M1, M2) devices, I tested it on a clear Intel Mac using brew install node and downloading Docker Desktop. I only tested the new version on the clean machine since the intent here is to make it fast for someone new to start.