Skip to content

Restore original deploy workflow - #4

Merged
paulgibbs merged 1 commit into
mainfrom
feature/alt-deploy-workflow
Mar 4, 2026
Merged

Restore original deploy workflow#4
paulgibbs merged 1 commit into
mainfrom
feature/alt-deploy-workflow

Conversation

@paulgibbs

@paulgibbs paulgibbs commented Mar 3, 2026

Copy link
Copy Markdown
Member

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:

  • Update the deployment job to use the shared indigotree/github-action-deploy-to-wpe composite action for plugins, modules, and theme deployments instead of direct wpengine deploy calls.
  • Bump the PHP version used in the deployment workflow from 8.2 to 8.4 and normalize workflow YAML formatting and environment handling.

Build:

  • Adjust the GitHub Actions deployment workflow configuration, including job structure and steps, without changing triggers or target branches.

@sourcery-ai

sourcery-ai Bot commented Mar 3, 2026

Copy link
Copy Markdown

Reviewer's Guide

Restores 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 workflow

sequenceDiagram
  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
Loading

File-Level Changes

Change Details Files
Normalize YAML formatting and indentation for the deployment workflow configuration.
  • Align top-level keys (on, env, jobs) with two-space indentation
  • Normalize indentation for steps, with/uniform two-space nesting
  • Keep branch triggers and environment variables functionally unchanged while making the file more readable
.github/workflows/deployments.yml
Refine pre-deploy validation job to use GitHub secrets to verify environment configuration.
  • Add job-level env variables mapping DEV_ENV/STG_ENV/PRD_ENV to corresponding secrets
  • Retain checks that ensure this is not the platform skeleton repo
  • Retain checks ensuring env values are set and match the GitHub secrets configuration
.github/workflows/deployments.yml
Simplify deploy job and revert to the previous WPE deploy implementation using a custom GitHub Action.
  • Keep Node.js setup (v22), npm ci, PHP setup, and Composer install with production flags
  • Remove dynamic WPE_ENV calculation step and per-step WPE_ENV wiring
  • Replace wpengine/github-action-wpe-site-deploy@v3 with indigotree/github-action-deploy-to-wpe@v0.4.0 for plugins, modules, and theme deployment
  • Switch path parameters from SRC_PATH/REMOTE_PATH to TPO_SRC_PATH/TPO_PATH expected by the restored action
  • Retain GitHub deployment creation and status reporting (in progress/success/failure) with octokit/request-action
.github/workflows/deployments.yml
Adjust PHP version used in the workflow.
  • Change setup-php from version 8.2 to 8.4 to match current platform targets
.github/workflows/deployments.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 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.
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>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +91 to +100
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 }}"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .github/workflows/deployments.yml
@paulgibbs
paulgibbs merged commit c47a217 into main Mar 4, 2026
5 checks passed
@paulgibbs
paulgibbs deleted the feature/alt-deploy-workflow branch March 4, 2026 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant