Add initial workflow for deploying the website to WP Cloud

[brandonpayton]

What is this PR doing?

This PR adds a workflow for deploying the playground.wordpress.net website to WP Cloud

Related to #1197

What problem is it solving?

Sometimes the website has availability issues due to its current shared hosting environment. Switching to WP Cloud is intended to address those issues.

Testing Instructions

• Make sure the new workflow completed successfully
• Test Playground using the temporary staging URL https://playground-dot-wordpress-dot-net.atomicsites.blog/

NOTE: There are some outstanding issues with rate-limiting that break certain aspects of WordPress Playground on the test site, but Playground should still load the WP home page. The rate-limiting issues will be addressed separately, and possibly with the host itself rather than in a follow-up PR.

[brandonpayton]

Tweaked this name so it is not the same as the existing deployment workflow.

[dmsnell]

I thought we could identify this in the on: section, and then the entire thing would only run on trunk or on merges into trunk.

with the if: I thought that the job will still run but fail. maybe I'm remembering backwards

[brandonpayton]

with the if: I thought that the job will still run but fail. maybe I'm remembering backwards

@dmsnell it sounds like this will just skip the specific job if the condition is not satisfied:
https://docs.github.com/en/actions/using-jobs/using-conditions-to-control-job-execution#example-only-run-job-for-specific-repository

We also have a condition set on the playground-wordpress-net-wp-cloud workflow environment that says it only runs on "Protected Branches", and in our case that means it only runs on "trunk".

I thought we could identify this in the on: section, and then the entire thing would only run on trunk or on merges into trunk.

It looks like it is also possible to filter on branch under the on:, but we don't use that in deploy-website.yml which is what this new workflow was adapted from.

[dmsnell]

if this step using another CI job? can we reuse the workflow and avoid this waiting code?

[brandonpayton]

@dmsnell, this is indeed duplicated code from deploy-website.yml, but once we are done migrating to the new host, I imagine we will remove the original workflow and leave this as the only remaining "waiting block".

I'm not sure if there is a way to avoid the waiting entirely... Are you thinking the waiting code may not be required at all if we take another approach, or do you just mean that we could avoid duplicating it?

[dmsnell]

I meant that maybe Github will schedule this Job once the previous one finishes, and we won't have to sit in a 10s wait loop. I have no idea if that's possible

[brandonpayton]

Ah, thanks. That's actually what this bit does:
https://github.com/WordPress/wordpress-playground/pull/1293/files#diff-e4927ad07277ff5004af1672f9a870dcf7c859ac71348aefd357ef9f30348d51R4-R8

A confusing thing is that the name within "build-website.yml" its name is "Deploy to playground.wordpress.net", which is the name the actual deploy workflow triggers on:

on:
     workflow_run:
         workflows: [Deploy to playground.wordpress.net]
         types:
             - completed

Apparently, based on the current deploy workflow, GH API still takes some time to reflect an artifact uploaded by the previous workflow, but I have not tested that assumption.

[adamziel]

The only reason building a website and deploying a website are separate workflows are GitHub limitations around downloading artifacts. Not going too deep into details, this PR is not subject to the same limitations. As soon as we can use rsync, we can build the website and deploy it from the same job. We don't need to use artifacts at all.

[brandonpayton]

👍 Thanks for explaining. It sounds like we can initially ship this separate workflow and merge it with the build workflow once playground.wordpress.net is totally moved to the new host.

Though it is not required, do you see any value in just saving a build artifact to keep a record of what was actually deployed?

[adamziel]

Though it is not required, do you see any value in just saving a build artifact to keep a record of what was actually deployed?

@brandonpayton Not at the moment:

• I never had to go back to review previous artifacts
• The current deployment workflow keeps a copy of the last website version for quick rollbacks if needed
• Rebuilding a historical commit is fast

I'm trying to think of a scenario where this would be useful and nothing comes up. Am I missing anything?

[brandonpayton]

@adamziel, I don't think you're missing anything. I asked because I like reproducibility but didn't really have an opinion on whether it mattered here. :) Thanks, we can just plan to drop the artifact in the future.

[adamziel]

LGTM and the deployment seems to have succeeded