Skip to content

docs(agents): clarify deploy environment target (staging vs production)#161

Merged
JohnRDOrazio merged 1 commit into
mainfrom
docs/deploy-environment-target
May 27, 2026
Merged

docs(agents): clarify deploy environment target (staging vs production)#161
JohnRDOrazio merged 1 commit into
mainfrom
docs/deploy-environment-target

Conversation

@JohnRDOrazio
Copy link
Copy Markdown
Member

@JohnRDOrazio JohnRDOrazio commented May 27, 2026

Documents the deploy.yml environment behavior, which previously bit a deploy:

  • A bare gh workflow run deploy.yml runs as staging (the workflow_dispatch default), which skips all WordPress theme/plugin steps (gated on ENVIRONMENT == 'production') — so backend changes don't ship, yet the run still goes green.
  • production ships frontend + backend (theme/plugin, OPcache flush); staging ships frontend only.
  • Backend changes (functions.php, REST handlers/routes, CPT/ACF) require -f environment=production.
  • Added how to verify the WP steps ran (not skipped) and a note on the transient kex_exchange_identification scp failure.

Docs-only (repo-root AGENTS.md, symlinked from CLAUDE.md); nothing deploys.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Updated deployment guidance with clearer environment-specific behaviors and differences.
    • Production deployments now explicitly include both frontend and backend components; staging environments deploy only the frontend infrastructure.
    • Enhanced deployment command examples, verification steps, and troubleshooting guidance for common issues including potential network-related failures.

Review Change Stack

The Deployment section showed only `gh workflow run deploy.yml`, which
runs as staging (the workflow_dispatch default) and silently skips all
WordPress theme/plugin steps — so backend changes don't ship even though
the run goes green. Document that:

- a release always deploys production;
- workflow_dispatch defaults to staging;
- production ships frontend + backend (theme/plugin), staging ships
  frontend only (WP steps are gated on ENVIRONMENT == 'production');
- backend changes require `-f environment=production`;
- how to confirm the WP steps ran (not skipped), plus the transient
  kex_exchange_identification scp failure.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@codacy-production
Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 27, 2026

📝 Walkthrough

Walkthrough

This PR updates AGENTS.md deployment guidance to clarify that GitHub Actions releases deploy to production (shipping both Next.js frontend and WordPress backend), while manual workflow_dispatch defaults to staging (frontend only). Expanded CLI command examples and verification steps replace the prior minimal snippet, and a note about transient SSH upload failures is included.

Changes

Deployment Documentation Update

Layer / File(s) Summary
Deployment guidance and CLI examples
AGENTS.md
Rewrote "Deployment" section to distinguish release-triggered production deployments from manual staging deployments, documented explicit environment shipping rules (production includes WordPress theme/plugin/OPcache steps; staging skips them), replaced minimal command snippet with expanded gh workflow run examples for environment selection, and added verification and SSH rate-limit troubleshooting guidance.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

  • CatholicOS/cdcf-website#51: Both PRs update deployment documentation around the same unified deploy.yml workflow behavior—using release: published for production and defaulting workflow_dispatch to staging with corresponding gh workflow run deploy.yml examples.

Poem

🐰 A rabbit hops through the docs with glee,
Deployment paths now crystal clear to see—
Release goes far, dispatch stays near,
With staging safe and production dear,
SSH hiccups? Just retry, my friend! 🚀

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically summarizes the main change: clarifying deployment environment targets and their behavior differences between staging and production.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch docs/deploy-environment-target

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@AGENTS.md`:
- Around line 256-277: Run Prettier to fix the formatting errors in AGENTS.md by
reformatting the file; specifically run the repository's prettier formatter
(e.g., prettier --write AGENTS.md) so the "Deploys via GitHub Actions" section,
code blocks (bash examples), bullet lists, and inline emphasis match the
project's style rules and CI will pass.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 20e0c439-6b90-40c5-9692-bddd9d367914

📥 Commits

Reviewing files that changed from the base of the PR and between 7d5b683 and f157b45.

📒 Files selected for processing (1)
  • AGENTS.md

Comment thread AGENTS.md
Comment on lines +256 to +277
Deploys via GitHub Actions (`deploy.yml`, SSH tar + scp). A published GitHub **release** always deploys to **production**. A manual `workflow_dispatch` takes an `environment` input (`production` or `staging`) that **defaults to `staging`**.

**The target controls what ships:**

- **`production`** — ships **both** the Next.js frontend **and** the WordPress backend (theme + plugin tarballs, plugin activation, OPcache flush). Use this for any change under `wordpress/themes/**` or `wordpress/plugins/**` — `functions.php`, REST handlers/routes, CPT/ACF registration, etc.
- **`staging`** — ships **only** the Next.js frontend. All WordPress theme/plugin steps are gated on `env.ENVIRONMENT == 'production'` and are **skipped** on staging (staging shares the production WP backend, so it must never push theme/plugin from a staging deploy).

> ⚠️ A bare `gh workflow run deploy.yml` runs as **staging**, so backend changes are **not** deployed — yet the run still succeeds (the frontend ships and smoke tests pass). Symptom: a new `cdcf/v1` route 404s or theme behaviour is unchanged after a "green" deploy. Always pass `-f environment=production` for backend changes.

```bash
gh workflow run deploy.yml # after pushing to main
# Deploy frontend + backend (theme/plugin changes) — after pushing to main:
gh workflow run deploy.yml -f environment=production

# Deploy frontend only (Next.js):
gh workflow run deploy.yml -f environment=staging # or just: gh workflow run deploy.yml

# Confirm the WP theme/plugin steps actually ran (must be `success`, not `skipped`):
gh run view <run-id> --json jobs \
-q '.jobs[].steps[] | select(.name|test("WP theme|OPcache|plugins")) | "\(.conclusion)\t\(.name)"'
```

The scp upload step occasionally fails transiently with `kex_exchange_identification: read: Connection reset by peer` (VPS SSH rate-limit after back-to-back deploys) — just re-run.
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Fix Prettier formatting issues.

The CI pipeline detected code style issues. Run the following command to fix them:

prettier --write AGENTS.md
🧰 Tools
🪛 LanguageTool

[uncategorized] ~260-~260: The official name of this content management system is spelled with a capital “P”.
Context: ...e flush). Use this for any change under wordpress/themes/** or wordpress/plugins/** — ...

(WORDPRESS)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@AGENTS.md` around lines 256 - 277, Run Prettier to fix the formatting errors
in AGENTS.md by reformatting the file; specifically run the repository's
prettier formatter (e.g., prettier --write AGENTS.md) so the "Deploys via GitHub
Actions" section, code blocks (bash examples), bullet lists, and inline emphasis
match the project's style rules and CI will pass.

@JohnRDOrazio JohnRDOrazio merged commit 7734514 into main May 27, 2026
10 of 11 checks passed
@JohnRDOrazio JohnRDOrazio deleted the docs/deploy-environment-target branch May 27, 2026 22:18
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