fix(deploy): read VPS_APP_DIR from vars instead of secrets#43
fix(deploy): read VPS_APP_DIR from vars instead of secrets#43JohnRDOrazio merged 2 commits intomainfrom
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 0/1 reviews remaining, refill in 21 minutes and 20 seconds.Comment |
Up to standards ✅🟢 Issues
|
Same fix as PR #43 applied to the staging workflow: NEXT_PUBLIC_* env vars are inlined at build time, so without setting it the staging client bundle (e.g. components/blog/ShareButtons.tsx) would ship the hardcoded production URL fallback instead of the staging URL. Reads from the new NEXT_PUBLIC_SITE_URL_STAGING repo variable so share buttons, sitemap canonicals, and other client-side absolute URLs on staging point to staging.catholicdigitalcommons.org. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The VPS_APP_DIR repo secret was moved to a repo variable. Without
this update the production deploy workflow expands ${{ secrets.VPS_APP_DIR }}
to an empty string and the SSH step would mkdir/tar/touch into the
wrong path, breaking deploys.
Mirrors the convention now used in deploy-staging.yml (PR #42) — an
app directory path isn't a credential, so it belongs in vars.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NEXT_PUBLIC_* env vars are inlined into the client bundle at build time, not read from process.env at runtime. The Plesk-panel value helps server code but client components (e.g. components/blog/ShareButtons.tsx) ship whatever was set when \`next build\` ran. Without this, the production bundle falls back to the hardcoded 'https://catholicdigitalcommons.org' literal in code — which happens to match prod, so it has been silently OK. Setting it from NEXT_PUBLIC_SITE_URL_PROD makes the configuration explicit and lets the staging workflow set its own value via NEXT_PUBLIC_SITE_URL_STAGING (see PR #42). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JohnRDOrazio
force-pushed
the
fix/prod-deploy-vps-app-dir-var
branch
from
b15ec6b to
1b9ba74
Compare
1 participant
Summary
Hotfix for the production
Build and Deployworkflow. TheVPS_APP_DIRGitHub secret was moved to a repo variable, butdeploy.ymlstill references${{ secrets.VPS_APP_DIR }}. Withoutthis change, the next production deploy would expand to an empty
string in the SSH command —
mkdir -p "",tar ... -C "",touch "/tmp/restart.txt"— silently breaking the deploy.Why this is urgent
Currently no scheduled deploys, but a
workflow_dispatchor releasepublication would fail until this lands.
Related
vars.*convention for the newVPS_STAGING_APP_DIRin the staging workflow.🤖 Generated with Claude Code