Simplify website deployment workflows #1404
Conversation
brandonpayton
had a problem deploying
to
playground-wordpress-net
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
force-pushed
the
single-website-deploy-workflow
branch
from
355d77a
to
eec2cd7
Compare
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
had a problem deploying
to
playground-wordpress-net-wp-cloud
GitHub Actions
Failure
brandonpayton
temporarily deployed
to
playground-wordpress-net-wp-cloud
GitHub Actions
Inactive
|
There were some SSH and pathing errors, but those are fixed now. This update was used to deploy to a staging site: This is ready for review. |
| @@ -6,6 +6,11 @@ on: | |||
| schedule: | |||
| - cron: '0 9,18 * * *' | |||
|
|
|||
| concurrency: | |||
| group: website-deployment | |||
There was a problem hiding this comment.
This ensures that only one website deployment workflow can run at a time.
| @@ -6,6 +6,11 @@ on: | |||
| schedule: | |||
| - cron: '0 9,18 * * *' | |||
|
|
|||
| concurrency: | |||
| group: website-deployment | |||
| # TODO: Enable cancel-in-progress once we are deploying per commit? | |||
There was a problem hiding this comment.
I'd let it finish – stopping the deployment halfway through or when the apply-update.sh is running sounds like trouble. If we push 5 commits in rapid progression, though, perhaps this could only run for the first and the fifth, but not for anything in between?
There was a problem hiding this comment.
I'd let it finish – stopping the deployment halfway through or when the apply-update.sh is running sounds like trouble.
Good point.
If we push 5 commits in rapid progression, though, perhaps this could only run for the first and the fifth, but not for anything in between?
That's my understanding: There can be one workflow instance active and one pending. If another becomes pending, it replaces the previous pending workflow.
|
Noting that this PR has put documentation out of sync: How do users download pre-built artifacts to self-host? |
What is this PR doing?
This PR simplifies website deployment workflows.
What problem is it solving?
Now that we are pushing built website files directly to WP Cloud, there is no longer any need to run deployment as a two-workflow process. It means we can just push the build directly rather than having to save it as a build artifact that is downloaded by the next workflow.
How is the problem addressed?
This PR merges the relevant steps from the second workflow into the first and deletes a lot of unnecessary code.
Testing Instructions
Test via workflow instrumentation and temporary changes to deploy to a staging site:
https://wordpress-playground-staging.atomicsites.blog