-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Store WordPress "build" directory as an artifact to enable live previews with Playground #5481
Conversation
This PR, paired with WordPress/wordpress-develop#5481, enables previewing WordPress Pull Requests. Changes: * Adds wordpress.html – an easy entrypoint to previewing PRs * Allows pulling GH artifacts from wordpress-develop repo * Patches the controlled iframe in JavaScript, not in Docker, to enable re-applying the patch in wordpress-develop branch #668 * Serves static files using the PHP instance when they exist, not based on heuristics like path.startsWith('/wp-content')
Note that this is a foundational item for https://core.trac.wordpress.org/ticket/59416 and will hopefully make it dramatically easier for folks to help test PRs. Thanks for the work on this @adamziel. This is so great, I LOVE IT!!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused as to why we're uploading the artifacts 3 times. Could you clarify?
Also, I'm wondering if there is a benefit to create a new workflow that's specifically meant to just build the package and upload it as an artifact. That would open the door to perform any other additional steps we may need down the road as well.
Add wordpress.html, a simple HTML form that enables previewing any WordPress core Pull Request. Technically, it's very similar to gutenberg.html – it just creates a tailored Blueprint and redirects to Playground with that Blueprint applied. *Caveats* This leans on storing WordPress builds as a GitHub artifact in CI. For now only one PR does that – WordPress/wordpress-develop#5481. Once it's merged, the previewer proposed in this PR will work for every wordpress-develop Pull Request! The downloaded WordPress bundle is ~45MB and takes a while to download without any visible progress information. Let's find a way to optimize it.
Add wordpress.html, a simple HTML form that enables previewing any WordPress core Pull Request. Technically, it's very similar to gutenberg.html – it just creates a tailored Blueprint and redirects to Playground with that Blueprint applied. *Caveats* This leans on storing WordPress builds as a GitHub artifact in CI. For now only one PR does that – WordPress/wordpress-develop#5481. Once it's merged, the previewer proposed in this PR will work for every wordpress-develop Pull Request! The downloaded WordPress bundle is ~45MB and takes a while to download without any visible progress information. Let's find a way to optimize it.
8c55316
to
3619be7
Compare
@desrosj that's what I meant by "it's overeager and tries to upload multiple times" in the description. No purpose in particular, I just ran out of time to fix it on Friday. I just corrected that so it only uploads the artifact once. I also applied the rest of your feedback, thank you! Right now I'm trying to figure out why GitHub is not running the workflow after I moved it to a separate |
Hmm, looking at the commit you made above, I'm not sure either. The Another thing I've been thinking about. Will these artifacts need to be available more widely? I think the current intent is to share a link within the context of a PR. But if we'd need to use the artifact anywhere else, I'm not sure if it's easy to retrieve the artifact. it may be worth looking at publishing these as a package on GitHub, or something similar. This may be a problem for a different day, though. |
It's not easy and I'd love to make it easy at one point. At the same time, artifacts solve a lot of problems, like cleaning up old files. I'd say let's move forward with them for now and let's explore more accessible uploads separately. |
Also, I found the problem with a separate workflow file. I forgot about the required |
And I just added a Does this look good, or do you see any blockers @desrosj? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, a few more thinks that I noticed!
Added a few small requests. Also, thinking about this more, if the intent is for this workflow to run on any branch, we will need to backport this and should wait until after WP 6.4 is branched to commit to avoid having to backport frequent changes to the 6.3 branch as we refine. I think it's fair to say we should only run this for PRs to and commits to |
One thing to keep in mind here is that this results in the zip file that is uploaded as an artifact being zipped again. It's not immediately apparent, but it may require an additional step when using the artifact. |
@desrosj good feedback, thank you! I just addressed all your notes.
Yes, I only want to run this for PRs so we're good.
This is fine, Playground can handle that – the Gutenberg repo does the same thing. |
That's due to a somewhat familiar issue with the
FWIW, the same tradeoff applies to Gutenberg (where it has confused users that uploaded the "double-zipped" |
Co-authored-by: Bernie Reiter <[email protected]>
Co-authored-by: Bernie Reiter <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Shall we wait for 6.4 to be branched from trunk
before landing this? 🤔 (That should happen shortly after RC1, which is scheduled for later tonight.)
This change matters for trunk Pull Requests and even if the workflow file changes, I don't think we'll need to backport that. I'll go ahead and merge. Feel free to revert if I'm wrong here. |
Add wordpress.html, a simple HTML form that enables previewing any WordPress core Pull Request. Technically, it's very similar to gutenberg.html – it just creates a tailored Blueprint and redirects to Playground with that Blueprint applied. *Caveats* This leans on storing WordPress builds as a GitHub artifact in CI. For now only one PR does that – WordPress/wordpress-develop#5481. Once it's merged, the previewer proposed in this PR will work for every wordpress-develop Pull Request! The downloaded WordPress bundle is ~45MB and takes a while to download without any visible progress information. Let's find a way to optimize it.
## What is this PR doing? Support for previewing wordpress-develop Pull Requests. <img width="1133" alt="CleanShot 2023-10-13 at 18 53 52@2x" src="https://github.com/WordPress/wordpress-playground/assets/205419/e30e9ac6-c99e-4e81-b68f-45e14116f6c9"> The previewer lives in `/wordpress.html` and supports a few query parameters: * `?pr=5481` – preview that PR * `?url=/wp-admin/post-new.php` – load that URL in WordPress * `?mode=seamless` – redirect to a full-screen Playground without the browser chrome and any other extra UI elements ## Caveats The downloaded WordPress bundle is ~45MB and takes a while to download without any visible progress information. Let's find a way to optimize it. ## Testing instructions 1. Go to http://localhost:5400/website-server/wordpress.html 2. Preview PR 5481 (no other PR works yet, see WordPress/wordpress-develop#5481) 3. Confirm in wp-admin the WordPress version is 6.4 dev ## Screenshots <img width="1286" alt="CleanShot 2023-10-13 at 18 58 36@2x" src="https://github.com/WordPress/wordpress-playground/assets/205419/ca25a714-4491-4f63-b82c-b2178a2828b5"> cc @spacedmonkey @fabiankaegy @dmsnell @jonathanbossenger @dawidurbanski
Creates a new GitHub workflow to expose WordPress build as a GitHub artifact. The goal is to enable previewing Pull Requests in WordPress Playground.
Related Playground PR WordPress/wordpress-playground#700
Trac Ticket: https://core.trac.wordpress.org/ticket/59416
cc @gziolo @youknowriad @peterwilsoncc @desrosj