Restore original deploy workflow - #4
Conversation
Reviewer's GuideRestores the original WP Engine deployment workflow by reverting to the earlier deployment action and simplifying environment handling, while keeping the existing pre-deploy checks and build steps largely intact. Sequence diagram for deploy job interactions in restored workflowsequenceDiagram
actor Developer
participant GitHub as GitHub
participant Workflow as Deploy_workflow
participant CheckJob as Job_check-project
participant DeployJob as Job_deploy
participant Octokit as Octokit_request_action
participant DeployAction as Deploy_to_WPE_action
participant WPEnv as WPEngine_environments
Developer->>GitHub: Push to main/staging/develop or manual dispatch
GitHub->>Workflow: Trigger deployments.yml
Workflow->>CheckJob: Start check-project
CheckJob->>CheckJob: Validate repository is not platform_skeleton
CheckJob->>CheckJob: Validate DEV_ENV STG_ENV PRD_ENV not CHANGE_ME
CheckJob->>CheckJob: Compare env vars with DEV_ENV STG_ENV PRD_ENV secrets
CheckJob-->>Workflow: Succeed or fail
Workflow->>DeployJob: Start deploy (needs check-project)
DeployJob->>DeployJob: Checkout code
DeployJob->>DeployJob: Setup Node and PHP 8.4
DeployJob->>DeployJob: Install npm and composer deps
DeployJob->>DeployJob: Build assets
DeployJob->>Octokit: Create GitHub deployment (environment based on ref)
Octokit-->>DeployJob: Deployment id
DeployJob->>Octokit: Set deployment status in_progress
loop For each deploy segment
DeployJob->>DeployAction: Run indigotree/github-action-deploy-to-wpe
DeployAction->>DeployAction: Resolve target envs from DEV_BRANCH STG_BRANCH PRD_BRANCH and DEV_ENV STG_ENV PRD_ENV
DeployAction->>WPEnv: rsync files via SSH using WPE_SSHG_KEY_PRIVATE
WPEnv-->>DeployAction: Deployment result
DeployAction-->>DeployJob: Step result
end
alt Deployment succeeded
DeployJob->>Octokit: Set deployment status success
else Deployment failed
DeployJob->>Octokit: Set deployment status failure
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- The PHP version has been bumped from 8.2 to 8.4 in the deploy workflow; if that wasn’t intentional for this project, consider aligning it with the runtime actually used in the target WP Engine environments.
- The
Set WPE_ENV from target branchstep has been removed and replaced with theindigotree/github-action-deploy-to-wpeinputs; please confirm that this action correctly derives the target environment for all branches you expect to deploy from (develop/staging/main) so you’re not relying on implicit behavior. - The final theme deployment step changed
CACHE_CLEARfromTRUEtoFALSE, which alters cache invalidation behavior on deploy; double-check this matches the intended rollout strategy for production and staging.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The PHP version has been bumped from 8.2 to 8.4 in the deploy workflow; if that wasn’t intentional for this project, consider aligning it with the runtime actually used in the target WP Engine environments.
- The `Set WPE_ENV from target branch` step has been removed and replaced with the `indigotree/github-action-deploy-to-wpe` inputs; please confirm that this action correctly derives the target environment for all branches you expect to deploy from (develop/staging/main) so you’re not relying on implicit behavior.
- The final theme deployment step changed `CACHE_CLEAR` from `TRUE` to `FALSE`, which alters cache invalidation behavior on deploy; double-check this matches the intended rollout strategy for production and staging.
## Individual Comments
### Comment 1
<location path=".github/workflows/deployments.yml" line_range="91-100" />
<code_context>
- echo "WPE_ENV=example" >> $GITHUB_ENV
- fi
-
- - name: Create release on Github
- id: create_deployment
- uses: octokit/request-action@v2.x
- with:
- route: POST /repos/{repository}/deployments
- repository: ${{ github.repository }}
- ref: ${{ github.ref_name }}
- environment: ${{ github.ref_name == 'main' && 'production' || github.ref_name }}
- auto_merge: false
- required_contexts: "[]"
- env:
- GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
-
- - name: Set deployment status to in progress
</code_context>
<issue_to_address>
**issue (bug_risk):** GITHUB_TOKEN may no longer have sufficient permissions for deployments/statuses after removing the explicit `permissions` block.
Previously, the workflow explicitly set `contents: write`, `deployments: write`, and `statuses: write`. Without that, it now falls back to the repo’s default token permissions (often `contents: read` only), so the `octokit/request-action` calls that create deployments and update statuses may start failing with 403s.
Please add a `permissions` section at the workflow or job level with at least `deployments: write` and `statuses: write` so these steps continue to work.
</issue_to_address>
### Comment 2
<location path=".github/workflows/deployments.yml" line_range="123-132" />
<code_context>
- uses: wpengine/github-action-wpe-site-deploy@v3
- with:
- # Deploy vars
- CACHE_CLEAR: FALSE
- FLAGS: "-azvr --inplace --verbose --ignore-existing --exclude-from=.deployignore"
- WPE_SSHG_KEY_PRIVATE: ${{ secrets.WPE_SSHG_KEY_PRIVATE }}
- WPE_ENV: ${{ env.WPE_ENV }}
-
- # PATHS:
- SRC_PATH: "wp-content/plugins"
- REMOTE_PATH: "wp-content"
-
- # Branches & environments
- DEV_BRANCH: ${{ env.DEV_BRANCH }}
- STG_BRANCH: ${{ env.STG_BRANCH }}
- PRD_BRANCH: ${{ env.PRD_BRANCH }}
- DEV_ENV: ${{ env.DEV_ENV }}
- STG_ENV: ${{ env.STG_ENV }}
- PRD_ENV: ${{ env.PRD_ENV }}
-
- - name: Deploy (modules)
</code_context>
<issue_to_address>
**question (bug_risk):** Changing the final theme/asset deploy to `CACHE_CLEAR: FALSE` alters cache invalidation behavior.
The previous workflow cleared WP Engine caches on the final deploy, but now all deploy steps use `CACHE_CLEAR: FALSE`. If this wasn’t intentional, users may not see new code/assets immediately after deployment. To retain prior behavior, set `CACHE_CLEAR: TRUE` on the final deploy step only.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| repository: ${{ github.repository }} | ||
| deployment: ${{ fromJson(steps.create_deployment.outputs.data).id }} | ||
| environment: ${{ github.ref_name == 'main' && 'production' || github.ref_name }} | ||
| log_url: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }} | ||
| description: Deploying ${{ github.sha }} to the ${{ github.ref_name }} environment. | ||
| state: in_progress | ||
| required_contexts: "[]" | ||
| env: | ||
| GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" | ||
|
|
There was a problem hiding this comment.
issue (bug_risk): GITHUB_TOKEN may no longer have sufficient permissions for deployments/statuses after removing the explicit permissions block.
Previously, the workflow explicitly set contents: write, deployments: write, and statuses: write. Without that, it now falls back to the repo’s default token permissions (often contents: read only), so the octokit/request-action calls that create deployments and update statuses may start failing with 403s.
Please add a permissions section at the workflow or job level with at least deployments: write and statuses: write so these steps continue to work.
Summary by Sourcery
Restore the WP Engine deployment workflow to use the shared indigotree deployment action and current runtime versions while keeping existing pre-deploy checks and deployment status reporting.
Enhancements:
Build: