search

WordPress / gutenberg.run

Gutenberg live branch preview provisioning service
https://playground.wordpress.net/gutenberg.html.
MIT License
25 stars 6 forks source link

Site image fails to be rebuilt, causing plugin install to eventually fail when Gutenberg requires newer WP. #18

Open iandunn opened 2 years ago

iandunn commented 2 years ago

This seems to be happening on every build (not just new/expired ones)

Command failed with exit code 1: docker exec [hash] /bin/sh -c curl https://gutenberg-artifact.aduth.workers.dev/39342 -o artifact.zip; unzip artifact.zip || exit 48; wp plugin install gutenbe...

https://github.com/WordPress/gutenberg.run/blob/1e9211fc209ed76d81f80904c2e22b1abf70b3ed/web/tasks/run/01-create-container.js#L125-L131

Sentry says it started on February 2nd.

cc @tellthemachines

dd32 commented 2 years ago 
# docker exec -ti 12c7f7aa1fd8 sh
$ wp plugin install gutenberg.zip --activate
Unpacking the package...
Installing the plugin...
Warning: The package could not be installed. "Your WordPress version is 5.7, however the uploaded plugin requires 5.8."
Plugin installation failed.
Warning: The 'gutenberg.zip' plugin could not be found.
Error: No plugins installed.

So the underlying issue is that containers are being created with WordPress 5.7 as the base (Which I've also confirmed).

The gutenberg.run handler seems to build the image once at startup, and never again.

I've re-created the image:

~/gutenberg.run/images/gutenbergrun-site# docker build -t gutenbergrun-site .

All steps ran from cache, including the wp core download step.

We should cause that step to be always run, through something like https://stackoverflow.com/questions/35134713/disable-cache-for-specific-run-commands but we can probably just download https://api.wordpress.org/core/stable-check/1.0/ into a file to cause the image to only need rebuilding when a new WordPress release happens.

That would then allow for the image rebuilding to be run on a cron task, or as part of the gutenberg.run JS.

I've rebuilt the image without using the cache;

~/gutenberg.run/images/gutenbergrun-site# docker build --no-cache -t gutenbergrun-site .
[...snip....]
---> Running in c3d10a7d5ebd
Downloading WordPress 5.9.2 (en_US)...
md5 hash verified: b5e9c3b8dfd767d55c3797c2eae0f57d
Success: WordPress downloaded.
Removing intermediate container c3d10a7d5ebd
 ---> 007b4a627f63
Step 20/20 : ENTRYPOINT [ "php", "-S", "0.0.0.0:9000" ]
 ---> Running in 0b66edb37900
Removing intermediate container 0b66edb37900
 ---> aad7c9099a95
Successfully built aad7c9099a95
Successfully tagged gutenbergrun-site:latest

Rebuilt successful, installed latest WordPress version, fired up another PR.. node still used the old tagged image - Gutenberg.run doesn't use the dynamic latest tag, instead it uses a tag specific to it, right now, that's gutenbergrun-site:1e9211fc209ed76d81f80904c2e22b1abf70b3ed.

Re-ran the build step, this time overwriting that image tag rather than latest.

Gutenberg.run is now operational again.

dd32 commented 2 years ago

right now, that's gutenbergrun-site:1e9211fc209ed76d81f80904c2e22b1abf70b3ed.

Turns out, that's the HEAD of the Git repo.

To refresh the cached site image, this can be used:

# cd ~/gutenberg.run/images/gutenbergrun-site; docker build -t gutenbergrun-site:`git rev-parse HEAD` .

This shouldn't be a crontab, but rather as an async task in the JS to rebuild the image when required. Can probably just be an hourly task to check the latest WP version matches the built image?