chore(infra): add CD pipeline and PM2 ecosystem config - #14
Conversation
…with GitHub Actions
…and ignore ecosystem file in linting
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ 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: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR introduces a complete continuous deployment pipeline. It adds a new GitHub Actions CD workflow that triggers on pushes to staging and main, runs the existing CI workflow as a prerequisite, and then deploys via SSH to remote servers using branch-specific environments. A new PM2 ecosystem configuration file defines process management and environment-specific settings. The ESLint configuration is updated to ignore the new PM2 config file. ChangesContinuous Deployment Pipeline
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 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 @.github/workflows/cd.yml:
- Line 36: The current DOTENV expression uses a brittle A && B || C pattern;
replace it by passing secrets.PRODUCTION_ENV and secrets.STAGING_ENV directly
into the job/env (e.g. export PRODUCTION_ENV, STAGING_ENV, REF_NAME) and add a
small script step (e.g. in the "Deploy via SSH" step or a pre-step) that sets
DOTENV based on REF_NAME (if REF_NAME == "main" use PRODUCTION_ENV else
STAGING_ENV) and immediately fails if DOTENV is empty. Ensure you reference
DOTENV, PRODUCTION_ENV, STAGING_ENV and REF_NAME in that step and write an
explicit non-empty check that exits with an error message when the chosen secret
is missing.
- Around line 46-59: The workflow fails on first deploy because the script runs
cd "$DEPLOY_DIR" before the directory exists; modify the sequence around
DEPLOY_DIR so you create the directory first (e.g., mkdir -p "$DEPLOY_DIR" or
check [ -d "$DEPLOY_DIR" ] and create it if missing) and only then cd into it,
then perform the existing git logic (the if block that checks for .git and runs
git clone --branch "$BRANCH" "$REPO" . or the fetch/reset path); ensure the
sequence around DEPLOY_DIR, cd "$DEPLOY_DIR", and the git clone --branch
"$BRANCH" "$REPO" . lines is reordered so clone is reachable on first run and
consider guarding the clone path against non-empty targets if needed.
- Around line 61-62: The .env file is written from the DOTENV variable using
printf and may be group/world readable; tighten permissions by ensuring umask is
set to 077 before writing or by immediately applying restrictive permissions
after writing (e.g., chmod 600 .env). Update the step that runs printf '%s\n'
"$DOTENV" > .env to either prefix it with a secure umask or follow it with a
chmod to ensure .env is only owner-readable.
- Line 14: Add a new reusable workflow file named ci.yml under .github/workflows
that declares on: workflow_call so the existing uses: ./.github/workflows/ci.yml
reference in the CD workflow resolves; inside ci.yml define the
inputs/permissions/jobs the CD workflow expects (match any expected
inputs/outputs and required permissions/secrets) and ensure the file is a valid
GitHub Actions workflow so the reusable call can execute successfully.
- Around line 76-81: Modify the pm2 restart invocation so it targets the
specific app name and updates environment variables: when checking and
restarting the process, call pm2 restart with the app scope "$APP_NAME" and
include the --update-env flag (i.e., use pm2 restart "$APP_NAME" --update-env or
pm2 restart ecosystem.config.cjs --env "$ENV_FLAG" "$APP_NAME" --update-env
depending on how the ecosystem is referenced) so env_production/env_staging
changes are loaded; keep the existing pm2 start behavior for the else branch and
retain pm2 save after the restart/start.
In `@ecosystem.config.cjs`:
- Around line 11-18: The env_production and env_staging blocks currently default
PORT to 5001/4001 which conflicts with the PR docs; update the PORT fallback in
the ecosystem config (env_production and env_staging) to match the documented
contract (use process.env.PORT || 3003 for env_production and process.env.PORT
|| 3004 for env_staging) or remove the fallback entirely so PORT is read
directly from process.env and missing values fail loudly; ensure NODE_ENV values
remain unchanged.
- Around line 4-9: Add explicit PM2 logging and graceful shutdown settings to
the process config: update the process block that defines name, script,
instances, exec_mode, autorestart, max_memory_restart to also set out_file and
error_file (or a combined file via merge_logs), enable merge_logs, set a
readable log_date_format, and increase kill_timeout to a safe value (e.g.,
several seconds) so Nest HTTP/DB connections can drain gracefully during
restarts; ensure these new properties are present alongside the existing keys
(name, script, instances, exec_mode, autorestart, max_memory_restart).
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 11ee6da9-42a2-41ec-91a0-c4a9c7c1dc42
📒 Files selected for processing (3)
.github/workflows/cd.ymlecosystem.config.cjseslint.config.mjs
| jobs: | ||
| ci: | ||
| name: CI Checks | ||
| uses: ./.github/workflows/ci.yml |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm ci.yml exists on this branch and declares workflow_call.
fd -t f 'ci\.yml$' .github/workflows
echo '---'
fd -t f 'ci\.yml$' .github/workflows --exec sh -c 'echo "== {} =="; cat {}'Repository: hngprojects/skillbridge-be
Length of output: 74
🏁 Script executed:
#!/bin/bash
# List all files in .github/workflows/
echo "=== Files in .github/workflows/ ==="
git ls-files .github/workflows/ | sort
echo ""
echo "=== Content of cd.yml around line 14 ==="
sed -n '10,20p' .github/workflows/cd.ymlRepository: hngprojects/skillbridge-be
Length of output: 417
Create .github/workflows/ci.yml with workflow_call trigger.
The reusable workflow referenced at line 14 does not exist in the repository. The uses: ./.github/workflows/ci.yml call will fail at runtime, blocking every deploy. Create ci.yml in .github/workflows/ and declare on: workflow_call: to enable this job to execute.
🧰 Tools
🪛 actionlint (1.7.12)
[error] 14-14: could not read reusable workflow file for "./.github/workflows/ci.yml": open /home/jailuser/git/.github/workflows/ci.yml: no such file or directory
(workflow-call)
🤖 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 @.github/workflows/cd.yml at line 14, Add a new reusable workflow file named
ci.yml under .github/workflows that declares on: workflow_call so the existing
uses: ./.github/workflows/ci.yml reference in the CD workflow resolves; inside
ci.yml define the inputs/permissions/jobs the CD workflow expects (match any
expected inputs/outputs and required permissions/secrets) and ensure the file is
a valid GitHub Actions workflow so the reusable call can execute successfully.
… validation and configure PM2 logging and lifecycle settings
…e/ci-cd-configuration
chore(infra): add CD pipeline and PM2 ecosystem config
2 participants
Description
Add CD pipeline and PM2 ecosystem configuration for automated deployments to staging and production environments.
Files added:
.github/workflows/cd.yml— CD workflow that SSHs into the server, pulls latest code, writes.env, installs dependencies, builds, runs migrations, and restarts the app via PM2.ecosystem.config.cjs— PM2 process config with environment-specific settings (ports, NODE_ENV) for staging and production.How it works:
staging→ deploys to~/skillbridge/backend/stagingon port 5001main→ deploys to~/skillbridge/backend/productionon port 4001STAGING_ENV,PRODUCTION_ENV)Related Issue (Link to Github issue)
N/A — infrastructure setup
Motivation and Context
The project had no automated deployment. Developers had to manually SSH into the server to deploy changes. This CD pipeline automates the full deploy flow (code pull → env setup → build → migrate → restart) and ensures CI passes before any deployment happens.
How Has This Been Tested?
Screenshots (if appropriate - Postman, etc):
N/A
Types of changes
Checklist:
Summary by CodeRabbit