Feature/frontend cicd#11
Conversation
feat: implement signup, sign in and verify email flow
…tend CI/CD pipeline
|
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 (1)
📝 WalkthroughWalkthroughThis PR introduces CI/CD infrastructure: a new CD pipeline for deploying to dev/staging/production environments via SSH and PM2, updates the CI workflow with shared environment variables and new security scanning jobs, and configures the PNPM workspace to manage build restrictions for specific dependencies. ChangesCI Pipeline Enhancement
CD Deployment Pipeline
Workspace Configuration
Possibly related PRs
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 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 |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 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:
- Around line 54-55: The workflow currently hardcodes NODE_ENV to "production"
by using "export NODE_ENV=production" (also duplicated later), which forces
dev/staging jobs into prod mode; remove the hardcoded export or replace it with
a dynamic/job-level value (e.g. export NODE_ENV=${{ env.NODE_ENV }} or simply
omit export so the job's NODE_ENV is inherited) and keep the PORT export if
needed (export PORT=3000) — update both occurrences where "export
NODE_ENV=production" appears.
- Around line 40-43: The deploy workflow is bypassing host verification by using
"StrictHostKeyChecking=no" in the ssh invocation and swallowing ssh-keyscan
errors with "|| true"; update the deploy step so the host key is reliably
installed and SSH fails if the host is unknown: run ssh-keyscan for $SSH_HOST
and ensure it appends to ~/.ssh/known_hosts without suppressing errors (remove
the "|| true" behavior), remove the "-o StrictHostKeyChecking=no" option from
the ssh command (or set it to "yes"), and ensure the workflow exits if
ssh-keyscan fails so deployments abort on unknown or changed host keys (refer to
the ssh invocation and the ssh-keyscan lines in the diff).
- Around line 42-45: The remote heredoc uses cd $DEPLOY_PATH but step-level env
vars aren’t forwarded over SSH, so ensure the remote receives the actual path:
either interpolate the variable on the runner into the SSH payload (replace cd
$DEPLOY_PATH with cd ${DEPLOY_PATH} expanded by GitHub Actions / use ${{
env.DEPLOY_PATH }}), or explicitly pass it into the remote shell (e.g., prefix
the ssh invocation with DEPLOY_PATH="${{ env.DEPLOY_PATH }}" bash -c 'ssh ...
"cd \"$DEPLOY_PATH\" && ..."', or pass it as an argument to the remote bash -s).
Update each heredoc block that uses DEPLOY_PATH (the ssh << 'EOF' sections) to
use one of these approaches so the remote cd uses a concrete value instead of an
empty variable.
In @.github/workflows/ci.yml:
- Around line 92-112: The workflow is missing a top-level permissions block
causing the github/codeql-action/upload-sarif@v2 step (used in the trivy job) to
fail; add a top-level permissions section (immediately after the on: section)
that includes security-events: write so the Upload SARIF step can write to the
Security tab, keeping other token permissions as needed (e.g., read for
contents) and ensuring the trivy job uses the repository token with those
permissions.
- Around line 99-101: Replace mutable action refs with immutable commit SHAs:
update aquasecurity/trivy-action@master to the full commit SHA that corresponds
to the desired release (e.g., the commit SHA for v0.35.0) and similarly replace
github/codeql-action/upload-sarif@v2 with its exact commit SHA; locate the
correct SHAs in each action's GitHub repo (Releases/Tags) and use the SHA form
(e.g., aquasecurity/trivy-action@<full-sha> and
github/codeql-action/upload-sarif@<full-sha>), optionally appending the
human-readable tag as a comment for clarity.
In `@pnpm-workspace.yaml`:
- Around line 4-7: The pnpm workspace contains an unsupported allowBuilds block
(symbols: allowBuilds, msw, sharp, unrs-resolver) which PNPM v9 ignores; remove
the entire allowBuilds section and rely on the existing ignoredBuiltDependencies
pattern (symbol: ignoredBuiltDependencies) to control build behavior
instead—delete lines defining allowBuilds and its entries so only
ignoredBuiltDependencies remains.
🪄 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: cf5f2949-0372-47b5-925f-d057e8341008
📒 Files selected for processing (3)
.github/workflows/cd.yml.github/workflows/ci.ymlpnpm-workspace.yaml
| ssh-keyscan -H "$SSH_HOST" >> ~/.ssh/known_hosts 2>/dev/null || true | ||
|
|
||
| ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@$SSH_HOST << 'EOF' | ||
| set -e |
There was a problem hiding this comment.
Host verification is effectively bypassed during SSH deploy.
At Line 42/109/176, StrictHostKeyChecking=no negates host authenticity checks; combined with ssh-keyscan ... || true (Line 40/107/174), this is vulnerable to MITM during deployment.
Also applies to: 107-110, 174-177
🤖 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 around lines 40 - 43, The deploy workflow is
bypassing host verification by using "StrictHostKeyChecking=no" in the ssh
invocation and swallowing ssh-keyscan errors with "|| true"; update the deploy
step so the host key is reliably installed and SSH fails if the host is unknown:
run ssh-keyscan for $SSH_HOST and ensure it appends to ~/.ssh/known_hosts
without suppressing errors (remove the "|| true" behavior), remove the "-o
StrictHostKeyChecking=no" option from the ssh command (or set it to "yes"), and
ensure the workflow exits if ssh-keyscan fails so deployments abort on unknown
or changed host keys (refer to the ssh invocation and the ssh-keyscan lines in
the diff).
| ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@$SSH_HOST << 'EOF' | ||
| set -e | ||
| cd $DEPLOY_PATH | ||
|
|
There was a problem hiding this comment.
DEPLOY_PATH is not guaranteed on the remote shell.
At Line 44/111/178, cd $DEPLOY_PATH runs inside a remote shell invoked via << 'EOF'; step-level env vars are not automatically forwarded over SSH, so this can resolve empty and deploy in the wrong directory.
Safer pattern: pass env vars explicitly to remote bash
-ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@$SSH_HOST << 'EOF'
+ssh -i ~/.ssh/deploy_key ${{ secrets.SSH_USER }}@$SSH_HOST \
+ "DEPLOY_PATH='${DEPLOY_PATH}' PORT='${PORT}' NODE_ENV='${NODE_ENV}' bash -se" << 'EOF'
set -e
-cd $DEPLOY_PATH
+cd "$DEPLOY_PATH"Also applies to: 109-112, 176-179
🤖 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 around lines 42 - 45, The remote heredoc uses cd
$DEPLOY_PATH but step-level env vars aren’t forwarded over SSH, so ensure the
remote receives the actual path: either interpolate the variable on the runner
into the SSH payload (replace cd $DEPLOY_PATH with cd ${DEPLOY_PATH} expanded by
GitHub Actions / use ${{ env.DEPLOY_PATH }}), or explicitly pass it into the
remote shell (e.g., prefix the ssh invocation with DEPLOY_PATH="${{
env.DEPLOY_PATH }}" bash -c 'ssh ... "cd \"$DEPLOY_PATH\" && ..."', or pass it
as an argument to the remote bash -s). Update each heredoc block that uses
DEPLOY_PATH (the ssh << 'EOF' sections) to use one of these approaches so the
remote cd uses a concrete value instead of an empty variable.
| export NODE_ENV=production | ||
| export PORT=3000 |
There was a problem hiding this comment.
Dev/Staging deployments are forcing production runtime mode.
At Line 54 and Line 121, NODE_ENV=production overrides the job env (development/staging), so both non-prod jobs run with prod runtime semantics.
Also applies to: 121-122
🤖 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 around lines 54 - 55, The workflow currently
hardcodes NODE_ENV to "production" by using "export NODE_ENV=production" (also
duplicated later), which forces dev/staging jobs into prod mode; remove the
hardcoded export or replace it with a dynamic/job-level value (e.g. export
NODE_ENV=${{ env.NODE_ENV }} or simply omit export so the job's NODE_ENV is
inherited) and keep the PORT export if needed (export PORT=3000) — update both
occurrences where "export NODE_ENV=production" appears.
| trivy: | ||
| name: Trivy Security Scan | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Run Trivy vulnerability scanner | ||
| uses: aquasecurity/trivy-action@master | ||
| with: | ||
| scan-type: "fs" | ||
| scan-ref: "." | ||
| format: "sarif" | ||
| output: "trivy-results.sarif" | ||
|
|
||
| - name: Upload Trivy results to GitHub Security tab | ||
| uses: github/codeql-action/upload-sarif@v2 | ||
| if: always() | ||
| with: | ||
| sarif_file: "trivy-results.sarif" | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For github/codeql-action/upload-sarif, which GITHUB_TOKEN permissions are required in GitHub Actions workflows?
💡 Result:
Required GITHUB_TOKEN permissions for github/codeql-action/upload-sarif (using the default GITHUB_TOKEN): 1) security-events: write - The action’s token input description states that the workflow must have security-events: write when using the built-in GitHub Actions token.[1] - GitHub’s SARIF upload docs likewise show security-events: write as required for all workflows using upload-sarif.[2][3] 2) (Only for private repositories) actions: read - GitHub’s SARIF upload docs show actions: read as “only required for workflows in private repositories”.[2][3] What to put in your workflow: permissions: security-events: write # only required for workflows in private repositories actions: read # (docs example also includes contents: read) contents: read Notes / scope: - The upload-sarif action relies on the built-in Actions token by default; if you set the token input explicitly, the same requirement (security-events: write) applies.[1]
Citations:
- 1: https://github.com/github/codeql-action/blob/main/upload-sarif/action.yml
- 2: https://docs.github.com/en/code-security/how-tos/find-and-fix-code-vulnerabilities/integrate-with-existing-tools/uploading-a-sarif-file-to-github
- 3: https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github
🏁 Script executed:
cat -n .github/workflows/ci.yml | head -50Repository: hngprojects/skillbridge-fe
Length of output: 1399
🏁 Script executed:
sed -n '85,120p' .github/workflows/ci.ymlRepository: hngprojects/skillbridge-fe
Length of output: 932
Add explicit security-events: write permission for SARIF upload.
The workflow lacks a permissions block at the top level. The github/codeql-action/upload-sarif@v2 action (line 108) requires security-events: write permission to upload SARIF results to GitHub's security tab. Without this, the upload will fail under restricted default token permissions.
Add the following permissions block after the on: section:
name: Frontend CI
on:
pull_request:
branches: [dev, staging, main]
push:
branches: [dev, staging, main]
+permissions:
+ contents: read
+ security-events: write
+
env:
NODE_VERSION: "20"
PNPM_VERSION: 9🤖 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/ci.yml around lines 92 - 112, The workflow is missing a
top-level permissions block causing the github/codeql-action/upload-sarif@v2
step (used in the trivy job) to fail; add a top-level permissions section
(immediately after the on: section) that includes security-events: write so the
Upload SARIF step can write to the Security tab, keeping other token permissions
as needed (e.g., read for contents) and ensuring the trivy job uses the
repository token with those permissions.
| - name: Run Trivy vulnerability scanner | ||
| uses: aquasecurity/trivy-action@master | ||
| with: |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the recommended secure pinning strategy for GitHub Actions (tag vs commit SHA), specifically for aquasecurity/trivy-action?
💡 Result:
The recommended secure pinning strategy for GitHub Actions, including aquasecurity/trivy-action, is to pin to a full commit SHA rather than a tag. Tags are mutable and can be force-pushed to point to malicious code, as seen in recent Trivy-related supply chain attacks [1][2][3]. GitHub explicitly recommends "Pin actions to a full length commit SHA" as the only way to use an action as an immutable release [4][5][6][7]. For aquasecurity/trivy-action specifically: - Use syntax like uses: aquasecurity/trivy-action@abc123def456... # v0.33.1 where the SHA corresponds to the desired release tag [8][9][10]. - The action internally calls aquasecurity/setup-trivy, which was previously pinned to a tag but updated to a commit SHA (e.g., e6c2c5e321ed9123bda567646e2f96565e34abe1 # v0.2.4) via PR #456 to support organizational SHA-only policies [11][12][9]. - Examples in the repo use tags like @0.33.1 for convenience, but for security, replace with the SHA from the tag [8][10][13]. - Tools like Dependabot can automate updates by creating PRs to refresh SHAs while preserving version comments [5][14]. This aligns with GitHub's security best practices and addresses issues raised in trivy-action repo discussions [11][12][15]. Note limitations: SHA pinning protects against tag hijacking but not orphaned commits from forks or unverified transitive dependencies [1][16][3].
Citations:
- 1: https://dev.to/ameer-pk/the-trivy-attack-why-sha-pinning-fails-github-actions-14if
- 2: https://www.reddit.com/r/programming/comments/1rzivdh/trivy_under_attack_again_widespread_github/
- 3: https://www.endorlabs.com/learn/github-actions-security-lessons-from-trivy
- 4: https://dev.to/nkuziev-sec/why-fixed-container-image-versions-matter-lessons-from-the-trivy-supply-chain-attack-29ke
- 5: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 6: Pin GitHub Actions to commit SHAs instead of version tags ankitects/anki#4722
- 7: https://docs.github.com/en/actions/how-tos/creating-and-publishing-actions/managing-custom-actions
- 8: https://github.com/aquasecurity/trivy-action
- 9: https://github.com/aquasecurity/trivy-action/blob/master/action.yaml
- 10: https://github.com/aquasecurity/trivy-action/tree/refs/heads/master
- 11: Pin aquasecuriy/setup-trivy to hash instead of tag aquasecurity/trivy-action#456
- 12: Allow pinning setup-trivy by hash aquasecurity/trivy-action#423
- 13: https://github.com/aquasecurity/trivy-action/tree/v0.35.0
- 14: https://github.com/mheap/pin-github-action
- 15: Support stronger pinning aquasecurity/trivy-action#464
- 16: https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '95,110p'Repository: hngprojects/skillbridge-fe
Length of output: 624
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '85,115p'Repository: hngprojects/skillbridge-fe
Length of output: 1046
🏁 Script executed:
cat -n .github/workflows/ci.yml | head -20Repository: hngprojects/skillbridge-fe
Length of output: 503
🏁 Script executed:
grep -n "permissions" .github/workflows/ci.ymlRepository: hngprojects/skillbridge-fe
Length of output: 52
Pin Trivy action to a full commit SHA instead of @master.
At line 100, aquasecurity/trivy-action@master uses a mutable reference and poses a supply-chain risk—@master can be force-pushed to point to malicious code. GitHub's security best practice is to pin GitHub Actions to full commit SHAs (e.g., aquasecurity/trivy-action@abc123def456... # v0.35.0), which are immutable. You can find the commit SHA corresponding to a release tag in the action's repository.
Additionally, github/codeql-action/upload-sarif@v2 (line 108) also uses a mutable tag; consider pinning it to a commit SHA as well.
🤖 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/ci.yml around lines 99 - 101, Replace mutable action refs
with immutable commit SHAs: update aquasecurity/trivy-action@master to the full
commit SHA that corresponds to the desired release (e.g., the commit SHA for
v0.35.0) and similarly replace github/codeql-action/upload-sarif@v2 with its
exact commit SHA; locate the correct SHAs in each action's GitHub repo
(Releases/Tags) and use the SHA form (e.g., aquasecurity/trivy-action@<full-sha>
and github/codeql-action/upload-sarif@<full-sha>), optionally appending the
human-readable tag as a comment for clarity.
| allowBuilds: | ||
| msw: false | ||
| sharp: false | ||
| unrs-resolver: false |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For PNPM v9, what are the valid pnpm-workspace.yaml keys to control dependency build scripts? Is allowBuildsvalid, or shouldonlyBuiltDependencies/ignoredBuiltDependencies be used instead?
💡 Result:
For pnpm v9, the workspace-level configuration keys for controlling which dependency build/lifecycle scripts are allowed are: 1) allowBuilds - Invalid for pnpm v9. It was introduced later (added in v10.26.0) as a replacement for the older build-approval settings. [1][2] 2) onlyBuiltDependencies - Valid in v9 (this is the allowlist-style setting used to restrict which dependencies may run lifecycle scripts). [1][3] 3) ignoredBuiltDependencies - Valid in v9 (used together with onlyBuiltDependencies to mute/ignore build execution for certain dependencies). [1][4] Recommendation (your question about what to use instead): - Do not use allowBuilds in pnpm v9. - Use onlyBuiltDependencies / ignoredBuiltDependencies (the older settings) to control dependency build script execution in v9. [1][3][4] Notes: - The newer allowBuilds model explicitly replaces onlyBuiltDependencies and ignoredBuiltDependencies, consolidating them into a single allow/disallow map. This replacement is described in the settings documentation (and is part of the reason allowBuilds is not applicable to v9). [1] Cited evidence: - allowBuilds “Added in: v10.26.0” and “replaces onlyBuiltDependencies and ignoredBuiltDependencies” [2][1] - The settings doc also explains the allowlist/ignored-builds migration and lists both onlyBuiltDependencies and ignoredBuiltDependencies as prior settings (replaced in v11+) [1][2] - approve-builds writes entries into the allowBuilds map (showing allowBuilds is the newer mechanism, not the v9 one) [4] If you share your exact pnpm-workspace.yaml (and whether you also set strictDepBuilds / strict-dep-builds), I can suggest the exact v9-compatible snippet.
Citations:
- 1: https://pnpm.io/settings
- 2: fix: write
allow-buildvalue topnpm-workspace.yamlpnpm/pnpm#9404 - 3:
approve-buildsreformats workspace file pnpm/pnpm#9470 - 4: https://pnpm.io/cli/approve-builds
🏁 Script executed:
# Check for pnpm version in common locations
find . -name ".npmrc" -o -name "pnpm-workspace.yaml" -o -name "package.json" | head -20Repository: hngprojects/skillbridge-fe
Length of output: 107
🏁 Script executed:
# Check the full pnpm-workspace.yaml file to understand current state
if [ -f "pnpm-workspace.yaml" ]; then
cat -n pnpm-workspace.yaml
fiRepository: hngprojects/skillbridge-fe
Length of output: 277
🏁 Script executed:
# Check for pnpm version in CI/CD or config files
if [ -f ".github/workflows" ] || [ -d ".github/workflows" ]; then
find .github -name "*.yml" -o -name "*.yaml" | xargs grep -l "pnpm" | head -5
fi
# Also check for .npmrc
if [ -f ".npmrc" ]; then
cat -n .npmrc
fiRepository: hngprojects/skillbridge-fe
Length of output: 120
🏁 Script executed:
# Check PNPM version in CI workflows
grep -n "pnpm" .github/workflows/ci.yml .github/workflows/cd.ymlRepository: hngprojects/skillbridge-fe
Length of output: 1688
🏁 Script executed:
# Check package.json for pnpm version constraint
cat -n package.json | head -30Repository: hngprojects/skillbridge-fe
Length of output: 1075
Remove allowBuilds—it is not supported in PNPM v9 and will be silently ignored.
The allowBuilds block at lines 4–7 is invalid for PNPM v9. This key was introduced in v10.26.0 and is not recognized by the pnpm version in use. The configuration will be silently ignored, leaving no build restrictions in place.
Use the existing ignoredBuiltDependencies pattern (already present at lines 8–10) instead. Remove lines 4–7:
Suggested fix
-allowBuilds:
- msw: false
- sharp: false
- unrs-resolver: false
ignoredBuiltDependencies:
- sharp
- unrs-resolver🤖 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 `@pnpm-workspace.yaml` around lines 4 - 7, The pnpm workspace contains an
unsupported allowBuilds block (symbols: allowBuilds, msw, sharp, unrs-resolver)
which PNPM v9 ignores; remove the entire allowBuilds section and rely on the
existing ignoredBuiltDependencies pattern (symbol: ignoredBuiltDependencies) to
control build behavior instead—delete lines defining allowBuilds and its entries
so only ignoredBuiltDependencies remains.
3 participants
Description
This PR for FE cd and fixing the ci syntax
Changes Proposed
What were you told to do?
What did you do?
Types of changes
Check List
Images
Summary by CodeRabbit