Add GitHub Environments support and rollback workflow#2
Add GitHub Environments support and rollback workflow#2rajivsinclair wants to merge 2 commits intomainfrom
Conversation
- test.yml: Run tests, lint on feature branches and PRs - deploy.yml: Build, push, and deploy on main/staging Migrating from CircleCI to GitHub Actions for CI/CD pipeline. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- Add environment configuration to deploy job for deployment tracking - Create rollback.yml workflow for easy rollbacks via GitHub Actions UI - Environments (production/staging) will appear in GitHub's Deployments tab 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
WalkthroughThree new GitHub Actions workflows are introduced for CI/CD automation: a test workflow that runs on pushes and pull requests, a deployment workflow that chains test → build-and-push → deploy to GKE with environment-specific configuration, and a manual rollback workflow for reverting Kubernetes deployments. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ 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 |
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to b3086bc in 2 minutes and 29 seconds. Click for details.
- Reviewed
284lines of code in3files - Skipped
0files when reviewing. - Skipped posting
4draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .github/workflows/deploy.yml:128
- Draft comment:
Consider using input redirection (e.g. 'envsubst < kubernetes/frontend.yml') instead of piping with cat for efficiency and clarity. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% This is a very minor stylistic suggestion. While technically correct (using input redirection is slightly more efficient than spawning a cat process), this is an extremely common pattern and the performance difference is negligible. The comment is about a code quality refactor, which the rules say can be good if "actionable and clear." However, this feels like a nitpick that doesn't provide significant value. The current code works fine and is a widely-used pattern. The rules also say "Do NOT comment unless there is clearly a code change required" and to not make comments that are "obvious or unimportant." This falls into the "unimportant" category - it's not a bug, security issue, or meaningful improvement. While this is technically a valid optimization, it's such a minor improvement that many experienced developers would consider it bikeshedding. The current pattern is extremely common in shell scripts and CI/CD pipelines, and the suggested change provides minimal practical benefit. Could this be considered too pedantic? Yes, this is too pedantic. The performance difference is negligible in a CI/CD context where much heavier operations are happening (Docker builds, Kubernetes deployments). This comment doesn't meet the bar of "clearly a code change required" - it's purely stylistic preference. This comment should be deleted. It's a minor stylistic suggestion that doesn't provide meaningful value. The current code is functional, widely-used, and the suggested improvement is negligible in this context.
2. .github/workflows/deploy.yml:50
- Draft comment:
Consider using the bash conditional [[ … ]] for string comparison instead of [ … ] for improved clarity and to avoid potential globbing issues. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment is suggesting a minor stylistic improvement from[ ]to[[ ]]. While[[ ]]is indeed a bash feature with some advantages, the current code is not incorrect and will work fine. The variable is properly quoted, so globbing issues won't occur. This seems like a code quality/style suggestion rather than fixing an actual bug. The rules state that code quality refactors are good "but only if they are actionable and clear" - this is actionable, but it's a very minor improvement. The rules also emphasize not commenting unless there's "clearly a code change required" and to avoid "obvious or unimportant" comments. This falls into the category of a minor style preference rather than a necessary change. The suggestion could be considered actionable and clear, and using[[ ]]is generally considered a bash best practice. The comment does provide a specific code suggestion that could marginally improve the code quality. Perhaps this is the type of refactor suggestion that should be kept. While[[ ]]is a best practice, the current code is not wrong and the benefits are minimal in this specific case. The rules emphasize not making "obvious or unimportant" comments and only commenting when there's "clearly a code change required". This is more of a stylistic preference than a required change, and the "globbing issues" mentioned are not actually a concern here since the variable is quoted. This comment should be deleted. It's a minor stylistic suggestion rather than a necessary code change. The current code works correctly and the suggested improvement provides minimal practical benefit in this context.
3. .github/workflows/rollback.yml:64
- Draft comment:
Wrap the revision input in quotes in the '--to-revision' argument to prevent issues if the input ever contains spaces or special characters. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment is about a change in the diff (this is a new file). The revision input is described as a "Revision number" which suggests it should be numeric. Kubernetes revision numbers are typically integers. If the input is always a number, spaces/special characters shouldn't be an issue. However, since it's defined astype: stringrather thantype: number, users could theoretically input non-numeric values. The comment suggests defensive programming. But is this really necessary? The input is user-provided via workflow_dispatch, and if they enter something invalid, kubectl would just fail with an error anyway. This seems like overly defensive programming for a case that shouldn't happen in normal usage. I might be missing that this is actually a best practice for shell scripts in GitHub Actions to always quote variable expansions. Even if the input is expected to be numeric, defensive quoting could prevent unexpected behavior. The inconsistency between line 66 (quoted) and line 67 (unquoted) might indicate this is worth fixing. While defensive quoting is generally good practice, this comment falls into the category of overly cautious suggestions. The revision number should be numeric based on the description, and if a user enters invalid input, kubectl will fail with a clear error message. This is not a critical bug or clear code quality issue - it's a minor defensive programming suggestion that may not be necessary. This comment suggests a minor defensive programming improvement but doesn't identify a clear bug. Since revision numbers should be numeric and invalid input would be caught by kubectl anyway, this is not a critical issue. The comment is somewhat pedantic and not clearly necessary.
4. .github/workflows/test.yml:23
- Draft comment:
Node.js version '14.15.3' is used; if possible, consider updating to a more recent LTS release to benefit from performance and security improvements. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment violates several rules: 1) It uses the phrase "if possible, consider" which is speculative and not definitive. 2) It's asking the author to consider something rather than pointing out a clear issue. 3) While Node.js 14 is EOL, the author may have intentionally chosen this version to match their project's requirements or existing infrastructure. 4) The comment doesn't provide a clear, actionable change - it just suggests "consider updating" without being definitive. 5) This is more of an informative/advisory comment rather than pointing out something that clearly needs to be fixed. However, using an EOL version of Node.js could be a legitimate security concern, and this might be important enough to warrant a comment. The author may not be aware that Node.js 14 is no longer supported. While security is important, the comment is phrased as a suggestion ("if possible, consider") rather than pointing out a definitive issue. The rules explicitly state not to make speculative comments or ask the author to confirm/consider things. If this were a critical security issue, it should be phrased more definitively. The author may have valid reasons for using this specific version. This comment should be deleted. It's advisory/suggestive rather than pointing out a clear issue that must be fixed. It uses "if possible, consider" language which violates the rule against speculative or non-definitive comments.
Workflow ID: wflow_mKGSrVMoCCWNIz3P
You can customize 
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Authenticate to Google Cloud | ||
| uses: google-github-actions/auth@v2 | ||
| with: | ||
| credentials_json: ${{ secrets.GCLOUD_SERVICE_KEY_BASE64 }} |
There was a problem hiding this comment.
The auth step feeds secrets.GCLOUD_SERVICE_KEY_BASE64 directly to google-github-actions/auth@v2 as credentials_json. The repo docs (docs/circleci.md#GCLOUD_SERVICE_KEY_BASE64) state this secret is the base64-encoded service account JSON, but the auth action expects raw JSON and will fail to parse a base64 string, causing GCP authentication (and thus the build/deploy pipeline and rollback workflow, which uses the same secret) to error out. Please decode the secret or store the unencoded JSON in GitHub Secrets before invoking the action.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
This PR adds GitHub Actions workflows to complement the existing CircleCI configuration, introducing deployment tracking through GitHub Environments and a rollback mechanism. The implementation closely mirrors the existing CircleCI patterns while leveraging GitHub-native features for better visibility.
Key Changes:
- Implements GitHub Environments (production/staging) with deployment tracking and environment URLs
- Adds a workflow_dispatch rollback workflow for easy rollbacks via GitHub UI
- Creates a test workflow that runs on feature branches and pull requests
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/workflows/test.yml | Runs tests and linting on feature branches and PRs, matching CircleCI test job functionality |
| .github/workflows/deploy.yml | Handles build, push to GCR, and GKE deployment for main/staging branches with environment tracking |
| .github/workflows/rollback.yml | Provides manual rollback capability through GitHub UI with revision selection support |
The workflows are well-structured and correctly implement the deployment patterns established in the CircleCI configuration. The code properly handles:
- Environment-specific configurations (production vs staging)
- Secrets management for GCP credentials and API keys
- Docker image tagging with build numbers
- Kubernetes deployment with envsubst templating
- Proper use of GitHub Actions features like environments, outputs, and conditional expressions
The implementation maintains consistency with the existing infrastructure while adding valuable GitHub-native deployment tracking and rollback capabilities.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
.github/workflows/test.yml (1)
23-27: Update Node.js to a supported LTS version.Node.js 14.15.3 reached end-of-life in April 2023 and no longer receives security updates. This poses a risk to supply chain security and may cause dependency compatibility issues.
Consider updating to a current LTS version (e.g., Node.js 20.x or 22.x). Verify that your application and dependencies remain compatible with the newer version.
.github/workflows/deploy.yml (1)
124-129: Verify envsubst variable safety in kubernetes/frontend.yml.Line 129 uses
envsubstto substitute variables in the Kubernetes manifest. This substitutes all$VARIABLEreferences in the file. Ensure that kubernetes/frontend.yml only contains expected variables (e.g.,$FRONTEND_IMAGE_TAG,$GOOGLE_PROJECT_ID) and does not accidentally expand unintended references (e.g., shell commands, YAML anchors, or other templating syntax).Consider using safer alternatives such as:
envsubstwith a whitelist:envsubst '$FRONTEND_IMAGE_TAG:$GOOGLE_PROJECT_ID'- A dedicated templating tool (e.g., Kustomize, Helm)
- Pre-processed manifests with explicit variable injection
.github/workflows/rollback.yml (2)
26-28: GitHub Environments protection policies should be configured.The rollback job uses
environment: name: ${{ inputs.environment }}which maps to GitHub Environments (production and staging). Ensure that these environments have appropriate protection rules configured in your GitHub repository settings, such as:
- Required reviewers to approve rollback operations
- Deployment branches restrictions (allow only main/staging)
- Custom deployment protection rules
This prevents accidental or unauthorized rollbacks.
64-70: Consider adding safeguards to revision input validation.The revision parameter is a free-form string that is directly passed to
kubectl rollout undo. While kubectl will reject invalid revision numbers, consider adding explicit validation or logging to provide clearer feedback if an invalid revision is provided:- name: Validate and rollback frontend deployment run: | if [ -n "${{ inputs.revision }}" ]; then echo "Rolling back to revision: ${{ inputs.revision }}" kubectl rollout undo deployment/ipno-frontend -n ${{ steps.set-ns.outputs.NAMESPACE }} --to-revision=${{ inputs.revision }} else echo "Rolling back to previous revision" kubectl rollout undo deployment/ipno-frontend -n ${{ steps.set-ns.outputs.NAMESPACE }} fiThis improves observability and makes it easier to debug rollback failures.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
.github/workflows/deploy.yml(1 hunks).github/workflows/rollback.yml(1 hunks).github/workflows/test.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Agent
| test: | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Node.js | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: '14.15.3' | ||
| cache: 'yarn' | ||
|
|
||
| - name: Install dependencies | ||
| run: yarn install --frozen-lockfile | ||
|
|
||
| - name: ESLint | ||
| run: yarn lint | ||
|
|
||
| - name: Run tests | ||
| run: yarn test:ci | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Extract duplicated test job into a reusable workflow.
The test job here duplicates the test.yml workflow verbatim. Consider refactoring to use a reusable workflow (.github/workflows/test.yml as a reusable job) to avoid maintenance drift and reduce code duplication.
Example approach:
jobs:
test:
uses: ./.github/workflows/test.ymlThis ensures the test configuration is defined once and reused consistently across both the test.yml and deploy.yml workflows.
🤖 Prompt for AI Agents
In .github/workflows/deploy.yml around lines 15–36 the "test" job duplicates the
same steps defined in .github/workflows/test.yml; extract that job into a
reusable workflow by replacing the inline job with a uses reference to the
reusable workflow (e.g. jobs.test.uses: ./.github/workflows/test.yml), forward
any required inputs or secrets and map needs/outputs if this deploy workflow
depends on other jobs, and remove the duplicated steps so the deploy workflow
calls the centralized test workflow instead.
| - name: Run tests | ||
| run: yarn test:ci | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git ls-files '.github/workflows/'Repository: PublicDataWorks/llead-frontend
Length of output: 160
🏁 Script executed:
cat -n .github/workflows/deploy.yml | sed -n '30,40p'Repository: PublicDataWorks/llead-frontend
Length of output: 321
🏁 Script executed:
cat -n .github/workflows/test.yml | sed -n '30,45p'Repository: PublicDataWorks/llead-frontend
Length of output: 549
Inconsistent test environment setup between workflows.
The test job in deploy.yml does not set JEST_JUNIT_OUTPUT_DIR: ./reports/ (present in test.yml line 37-38), which may cause test results to not be captured in the expected location. Add the environment variable to match the test.yml configuration:
- name: Run tests
run: yarn test:ci
env:
JEST_JUNIT_OUTPUT_DIR: ./reports/
🤖 Prompt for AI Agents
.github/workflows/deploy.yml around lines 34 to 36: the Run tests step omits the
JEST_JUNIT_OUTPUT_DIR environment variable so test artifacts may not be written
to ./reports/ as in test.yml; update the Run tests step to include an env block
with JEST_JUNIT_OUTPUT_DIR: ./reports/ so the workflow uses the same test output
directory as test.yml.
Summary
Features
🤖 Generated with Claude Code
Important
Add GitHub Actions workflows for deployment tracking, rollback, and testing with environment support.
deploy.yml):mainandstagingbranches.rollback.yml):workflow_dispatch.kubectlto manage rollbacks on GKE.test.yml):This description was created by
for b3086bc. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.