Move gitlab cicd to github actions #1
Conversation
WalkthroughThis update migrates CI/CD workflows from GitLab to GitHub Actions, introducing new YAML workflow files for backend, frontend, and infrastructure pipelines. Several Terraform modules now declare explicit provider and version requirements. Minor code clean-ups and variable removals are made in Terraform modules, and a formatting tweak is applied to a React component. Additionally, the Stripe secret key is now sourced from environment variables instead of a hardcoded string, and obsolete comments were removed from frontend API route files. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GitHub as GitHub
participant Actions as GitHub Actions Runner
participant Backend as Backend Codebase
participant Frontend as Frontend Codebase
participant Infra as Infrastructure Codebase
Dev->>GitHub: Open Pull Request or Manually Trigger Workflow
GitHub->>Actions: Start Backend Workflow
Actions->>Backend: Run Linting (Checkstyle)
Actions->>Backend: Run Unit Tests (after lint success)
GitHub->>Actions: Start Frontend Workflow
Actions->>Frontend: Run Linting (npm run lint)
Actions->>Frontend: Run Cypress Component Tests (after lint success)
GitHub->>Actions: Start Infrastructure Workflow
Actions->>Infra: Run TFLint for Terraform Linting
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
infrastructure/remote/modules/elasticache/main.tf (1)
1-9: Duplicate of IAM module’s version-pinning guidance
See the comment ininfrastructure/remote/modules/iam/main.tfregarding adding an upper bound (e.g.~> 5.60.0) to the AWS provider constraint.
🧹 Nitpick comments (16)
infrastructure/remote/modules/cognito/main.tf (1)
4-7: Consider tightening the AWS provider constraint
To reduce the risk of future breaking changes, you could pin an upper bound on the AWS provider, for example:version = ">= 5.60.0, < 6.0.0"Or use the
~>operator to allow only non-breaking patches:version = "~> 5.60.0"infrastructure/remote/modules/ssm/main.tf (1)
3-9: Declare AWS provider requirement
Therequired_providersblock correctly pins the AWS provider source and ensures version >= 5.60.0. As an optional improvement, you might consider using the pessimistic version constraint (~> 5.60.0) to limit upgrades to non-breaking changes within the 5.x series.infrastructure/remote/modules/kafka/main.tf (2)
1-2: Consider tightening the Terraform version constraintRather than
>= 1.9, specifying an upper bound can prevent unexpected breaking changes with future Terraform 2.x releases. For example:required_version = ">= 1.9.0, < 2.0.0"
5-7: Pin AWS provider with minor version compatibilityUsing
>= 5.60.0allows any newer major version, which may introduce breaking changes. Consider a constraint like:version = "~> 5.60"to automatically pick up patch releases but avoid major upgrades.
infrastructure/remote/modules/rds/main.tf (1)
3-9: Use pessimistic provider version constraints.Currently
version = ">= 5.60.0"will permit unintended major or minor upgrades that could introduce breaking changes. Consider switching to a pessimistic constraint to lock to the 5.60.x series and receive only non-breaking patch updates:required_providers { aws = { source = "hashicorp/aws" - version = ">= 5.60.0" + version = "~> 5.60.0" } }.github/workflows/backend.yml (3)
7-7: Remove trailing spaces
Line 7 contains unnecessary trailing whitespace which should be removed to satisfy YAML lint rules.- " "🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 7-7: trailing spaces
(trailing-spaces)
22-30: Consider caching Maven dependencies to speed up CI
Adding a cache step for the Maven local repository can reduce build times by reusing downloaded dependencies across runs.Example addition after the checkout step:
- name: Checkout code uses: actions/checkout@v4 + - name: Cache Maven local repository + uses: actions/cache@v3 + with: + path: ~/.m2/repository + key: ${{ runner.os }}-m2-${{ hashFiles('**/backendService/pom.xml') }} + restore-keys: | + ${{ runner.os }}-m2-
56-56: Ensure newline at end of file
A trailing newline is missing at the end of the file. Adding one will prevent YAML lint errors and ensure consistent behaviour across tools.+ (add newline)🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 56-56: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/frontend.yml (4)
3-4: Consider restricting pull_request triggers to target branches
Currently the workflow runs on every pull request across all branches. You may want to limit this to specific branches (e.g.main,develop) to avoid unnecessary runs:on: pull_request: branches: - main - develop workflow_dispatch:
25-28: Avoid copying.env.example—use nativeenvmappings
Copying the example file at runtime can lead to drift if.env.exampleisn’t kept in sync. Instead, inject needed variables via theenv:block at the job or step level.- name: Lint frontend env: NODE_ENV: test API_URL: https://api.example.com run: npm run lint
56-61: Speed up Docker builds with layer caching
Rebuilding the Docker image every run can be slow. Consider adding Docker layer caching viaactions/cacheor GitHub’s built-indocker/build-push-actioncache support:- name: Build with cache uses: docker/build-push-action@v4 with: context: . cache-from: type=gha cache-to: type=gha,mode=max tags: frontend-test-image
62-67: Pin to latest Cypress GitHub Action and validate wait-on
You’re usingcypress-io/github-action@v6.5.0. Ensure this is the intended major version and consider pinning tov6to automatically get minor fixes. Also verify thatlocalhost:3000/api/healthis exposed by your Docker Compose setup.infrastructure/remote/modules/route53/certificates.tf (1)
3-8: Simplify and avoid nested interpolation in domain names
The duplication of the conditional logic inside bothdomain_nameand the SANs causes nested${}blocks. You can extract a local and reuse it to improve readability and avoid parse pitfalls:locals { base_domain = var.environment == "prod" ? var.domain : "${var.environment}.${var.domain}" } resource "aws_acm_certificate" "acm_certificate" { domain_name = local.base_domain subject_alternative_names = ["www.${local.base_domain}"] … }.github/workflows/infrastructure.yml (3)
2-4: Suggest scoping workflow to infrastructure changes.To avoid running lint checks on unrelated pull requests, consider adding a
pathsfilter underon.pull_requestso this workflow only triggers when files in theinfrastructure/directory are modified. For example:on: - pull_request: + pull_request: + paths: + - 'infrastructure/**'
6-7: Align job name with implemented steps.The job is named
lint-and-security-scan-infrastructurebut only runs TFLint. Either rename it (e.g.infrastructure-lint) or add a security scanning step (such as tfsec) to fulfil the “security-scan” aspect.
26-26: Add newline at end of file and remove trailing spaces.YAMLLint flags missing newline and trailing spaces at EOF. Ensure the file ends with a single newline and no extra spaces.
Example diff:
@@ .github/workflows/infrastructure.yml -<remove trailing spaces on this line> +🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 26-26: no new line character at the end of file
(new-line-at-end-of-file)
[error] 26-26: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
.github/workflows/backend.yml(1 hunks).github/workflows/frontend.yml(1 hunks).github/workflows/infrastructure.yml(1 hunks).gitlab-ci.yml(0 hunks)CICD/gitlab/backend.yml(0 hunks)CICD/gitlab/frontend.yml(0 hunks)CICD/gitlab/terraform.yml(0 hunks)frontend/src/components/ui/Sidebar.tsx(1 hunks)infrastructure/remote/modules/cicd/main.tf(1 hunks)infrastructure/remote/modules/cicd/secrets.tf(0 hunks)infrastructure/remote/modules/cicd/variables.tf(0 hunks)infrastructure/remote/modules/cognito/main.tf(1 hunks)infrastructure/remote/modules/ecr/main.tf(1 hunks)infrastructure/remote/modules/ecs/main.tf(1 hunks)infrastructure/remote/modules/elasticache/main.tf(1 hunks)infrastructure/remote/modules/elasticache/variables.tf(0 hunks)infrastructure/remote/modules/iam/ecs.tf(1 hunks)infrastructure/remote/modules/iam/main.tf(1 hunks)infrastructure/remote/modules/kafka/main.tf(1 hunks)infrastructure/remote/modules/networking/main.tf(1 hunks)infrastructure/remote/modules/rds/main.tf(1 hunks)infrastructure/remote/modules/route53/certificates.tf(1 hunks)infrastructure/remote/modules/route53/main.tf(1 hunks)infrastructure/remote/modules/route53/routes.tf(1 hunks)infrastructure/remote/modules/s3/main.tf(1 hunks)infrastructure/remote/modules/ses/main.tf(1 hunks)infrastructure/remote/modules/ssm/main.tf(1 hunks)infrastructure/remote/variables.tf(1 hunks)infrastructure/shared/dynamodb/main.tf(1 hunks)infrastructure/shared/s3/images-bucket.tf(1 hunks)
💤 Files with no reviewable changes (7)
- infrastructure/remote/modules/elasticache/variables.tf
- infrastructure/remote/modules/cicd/secrets.tf
- infrastructure/remote/modules/cicd/variables.tf
- CICD/gitlab/terraform.yml
- CICD/gitlab/frontend.yml
- .gitlab-ci.yml
- CICD/gitlab/backend.yml
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/infrastructure.yml
[error] 26-26: no new line character at the end of file
(new-line-at-end-of-file)
[error] 26-26: trailing spaces
(trailing-spaces)
.github/workflows/backend.yml
[error] 7-7: trailing spaces
(trailing-spaces)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 56-56: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (17)
infrastructure/remote/modules/cognito/main.tf (1)
1-9: Standardised Terraform and AWS provider requirements look good
Thisterraformblock correctly enforces Terraform ≥ 1.9 and the AWS provider ≥ 5.60.0, matching the conventions introduced across your other modules to prevent unchecked version drift.infrastructure/remote/modules/ssm/main.tf (1)
1-2: Enforce minimum Terraform version
Definingrequired_version = ">= 1.9"guarantees that anyone using this SSM module has a Terraform CLI that supports its syntax and features.infrastructure/remote/modules/kafka/main.tf (1)
1-9: Consistent Terraform version requirementsThis
terraformblock correctly pinsrequired_versionand the AWS provider, mirroring other modules’ standards and ensuring compatibility across your infrastructure modules.infrastructure/remote/modules/rds/main.tf (1)
1-2:Details
✅ Verification successful
Ensure Terraform CLI version consistency.
The
required_version = ">= 1.9"constraint should align with the requirements declared in other remote modules to prevent drift in the Terraform CLI versions used across your stacks.You can verify consistency by running:
🏁 Script executed:
#!/bin/bash # Verify required_version across all remote modules rg -R 'required_version\s*=' -n infrastructure/remote/modulesLength of output: 468
🏁 Script executed:
#!/bin/bash # Correctly verify required_version across all remote modules rg 'required_version\s*=' -n infrastructure/remote/modulesLength of output: 1047
Terraform CLI Version Constraint Consistency Verified
All remote modules under
infrastructure/remote/modulesdefinerequired_version = ">= 1.9", matching the RDS module. No changes are needed.infrastructure/remote/modules/ecr/main.tf (1)
1-9:Details
✅ Verification successful
Explicit Terraform & AWS provider version constraints added
Adding
required_versionandrequired_providerspins ensures this module is only used with Terraform ≥ 1.9 and AWS provider ≥ 5.60.0. Please verify that all other remote modules declare the same constraints to avoid version drift, and consider centralising provider version pins in the root module for easier maintenance.
🏁 Script executed:
#!/usr/bin/env bash # Verify consistency of provider constraints across all remote modules rg -R "required_providers" -A3 infrastructure/remote/modules/Length of output: 466
🏁 Script executed:
#!/usr/bin/env bash # Verify Terraform & AWS provider version constraints across all remote modules rg "required_version" -A2 infrastructure/remote/modules/ rg "required_providers" -A4 infrastructure/remote/modules/Length of output: 6913
All remote modules use Terraform ≥1.9 & AWS provider ≥5.60.0
Verified that eachinfrastructure/remote/modules/*/main.tfdeclares:
required_version = ">= 1.9"required_providerswithaws = { source = "hashicorp/aws", version = ">= 5.60.0" }Consider centralising these provider version pins in the root module for easier maintenance.
infrastructure/remote/modules/networking/main.tf (1)
1-9: Excellent addition of explicit version constraints.This follows Terraform best practices by defining explicit version requirements for both Terraform and the AWS provider, ensuring consistent infrastructure deployments across environments.
infrastructure/shared/dynamodb/main.tf (1)
1-9: Consistent version requirements across modules.Good to see identical version constraints being applied consistently across different Terraform modules, ensuring a standardised infrastructure environment.
infrastructure/remote/modules/cicd/main.tf (1)
1-9: Version requirements align well with CI/CD migration.These explicit version constraints are particularly important for the CI/CD module, ensuring that the new GitHub Actions workflows will have consistent Terraform environments during infrastructure deployments.
infrastructure/remote/modules/route53/main.tf (1)
1-9: Completes the standardisation across infrastructure modules.This final addition of version constraints maintains consistency across all Terraform modules, creating a reliable and predictable infrastructure environment.
frontend/src/components/ui/Sidebar.tsx (1)
47-49: Improved code readability through better formatting.The multi-line format with parentheses enhances readability whilst maintaining the same filtering logic for excluding the "Items" link when no account ID exists.
infrastructure/remote/modules/s3/main.tf (1)
1-9: Standardise Terraform and AWS provider constraints
Introducing theterraformblock withrequired_version = ">= 1.9"andawsprovider>= 5.60.0ensures that everyone uses a compatible Terraform and AWS provider version. This aligns perfectly with the other modules in the repo and prevents subtle version-related issues.infrastructure/remote/modules/ecs/main.tf (1)
1-9: Standardise Terraform and AWS provider constraints
The newterraformblock correctly enforces Terraform ≥ 1.9 and AWS provider ≥ 5.60.0. This consistent version gating across modules will improve reproducibility and avoid drift.infrastructure/shared/s3/images-bucket.tf (1)
1-9: Standardise Terraform and AWS provider constraints
Adding theterraformblock at the top brings shared modules into alignment with the remote modules, enforcing Terraform ≥ 1.9 and AWS provider ≥ 5.60.0. This uniformity helps catch incompatible versions early.infrastructure/remote/modules/ses/main.tf (1)
1-9: Standardise Terraform and AWS provider constraints
Theterraformblock specifyingrequired_version = ">= 1.9"and AWS provider>= 5.60.0is correctly applied here, ensuring the SES module uses the same version constraints as the other modules..github/workflows/frontend.yml (1)
18-21: Well-done pinning Node.js version and enabling npm cache
Usingactions/setup-node@v4withnode-version: 20.xandcache: npmimproves reproducibility and performance.Also applies to: 44-47
infrastructure/remote/modules/iam/ecs.tf (1)
122-122: Approved: switch interpolation to direct variable reference
Changing from"${var.admin_access_logs_table_arn}"tovar.admin_access_logs_table_arnsimplifies the HCL without altering semantics.infrastructure/remote/modules/route53/routes.tf (1)
5-5: Approve simplification of string interpolation.The conditional removal of interpolation for the prod case is correct and enhances readability by avoiding unnecessary
${}syntax whenvar.domaincan be used directly.
| # variable "apollo_gateway_image_tag" { | ||
| # description = "The tag of the apollo gateway Docker image to deploy" | ||
| # type = string | ||
| # default = "latest" | ||
| # } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Avoid leaving commented-out Terraform variables
Commenting out a variable block can clutter your configuration and confuse future maintainers. If apollo_gateway_image_tag is genuinely no longer used, remove these lines entirely. If you intend to re-enable it in future, add a deprecation notice explaining why it’s disabled rather than simply commenting it out.
Verify there are no remaining references to this variable in the repo:
🏁 Script executed:
#!/bin/bash
# Search for any usage of apollo_gateway_image_tag
rg -n 'apollo_gateway_image_tag' .Length of output: 446
Remove all commented-out apollo_gateway_image_tag occurrences
No active references to apollo_gateway_image_tag remain—only commented-out definitions and usages. Please remove these lines entirely (or, if you need to preserve them for future use, replace them with a proper deprecation notice):
• infrastructure/remote/variables.tf (around line 64)
• infrastructure/remote/main.tf (around line 71)
• infrastructure/remote/modules/ecs/variables.tf (around line 66)
• infrastructure/remote/modules/ecs/task_definitions.tf (around line 134)
🤖 Prompt for AI Agents
In infrastructure/remote/variables.tf around lines 64 to 68, remove the entire
commented-out variable block for apollo_gateway_image_tag since it is no longer
used anywhere in the repo. Also, remove all other commented-out occurrences of
this variable in infrastructure/remote/main.tf near line 71,
infrastructure/remote/modules/ecs/variables.tf near line 66, and
infrastructure/remote/modules/ecs/task_definitions.tf near line 134 to clean up
the codebase and avoid confusion.
| terraform { | ||
| required_version = ">= 1.9" | ||
| required_providers { | ||
| aws = { | ||
| source = "hashicorp/aws" | ||
| version = ">= 5.60.0" | ||
| } | ||
| } | ||
| } No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Tighten Terraform & provider version constraints
Unbounded >= constraints can introduce breaking changes when Terraform 2.0 or AWS provider 6.x are released. It’s safer to pin to a minor-range, for example:
terraform {
required_version = "~> 1.9"
required_providers {
aws = {
source = "hashicorp/aws"
- version = ">= 5.60.0"
+ version = "~> 5.60.0"
}
}
}This prevents unintended upgrades beyond the tested provider series.
🤖 Prompt for AI Agents
In infrastructure/remote/modules/iam/main.tf lines 1 to 9, the Terraform and AWS
provider version constraints use unbounded >= operators, which can lead to
unintended upgrades and potential breaking changes. Change the required_version
from ">= 1.9" to "~> 1.9" and the AWS provider version from ">= 5.60.0" to "~>
5.60.0" to restrict upgrades to the specified minor version range and avoid
automatic major version updates.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/backend.yml(1 hunks).github/workflows/frontend.yml(1 hunks).github/workflows/infrastructure.yml(1 hunks)frontend/src/app/api/billing/payments/route.ts(0 hunks)frontend/src/app/api/billing/subscriptions/route.ts(0 hunks)frontend/src/utils/stripe.ts(1 hunks)
💤 Files with no reviewable changes (2)
- frontend/src/app/api/billing/payments/route.ts
- frontend/src/app/api/billing/subscriptions/route.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/infrastructure.yml
- .github/workflows/backend.yml
- .github/workflows/frontend.yml
🔇 Additional comments (1)
frontend/src/utils/stripe.ts (1)
15-77: Well-structured utility functions.The Stripe utility functions are well-documented, properly typed, and follow good separation of concerns. The logic for finding customers and subscriptions is clear and maintainable.
| const stripe = new Stripe( | ||
| "sk_test_51QNhlTGlnq0aqIkWUh4pGdNEkLo6qGgkXU885vaJexq15ykuThU9JDTxo77RTjCqNxRP6QkW30y7cZEIOLEpn6KD00uBKttude", | ||
| ); | ||
| const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Excellent security improvement!
Moving from a hardcoded secret key to an environment variable is a significant security enhancement. The existing validation on lines 3-5 ensures the application fails fast if the environment variable isn't configured.
However, please ensure that STRIPE_SECRET_KEY is properly configured in your new GitHub Actions workflows.
🏁 Script executed:
#!/bin/bash
# Description: Verify that STRIPE_SECRET_KEY is configured in GitHub Actions workflows
# Expected: Find references to STRIPE_SECRET_KEY in workflow files
echo "Searching for STRIPE_SECRET_KEY in GitHub Actions workflows..."
fd -e yml -e yaml . .github/workflows/ --exec grep -l "STRIPE_SECRET_KEY" {}Length of output: 213
🏁 Script executed:
#!/bin/bash
# Description: Re-run a search for STRIPE_SECRET_KEY in GitHub Actions workflows using grep for reliability
echo "Searching for STRIPE_SECRET_KEY in .github/workflows..."
grep -R "STRIPE_SECRET_KEY" -n .github/workflows || echo "No occurrences found"Length of output: 220
Missing STRIPE_SECRET_KEY in GitHub Actions workflows
I re-ran a search across .github/workflows and found no references to STRIPE_SECRET_KEY. Without this in your workflows, jobs that initialise Stripe will fail at runtime.
• Add STRIPE_SECRET_KEY as a repository secret in GitHub.
• Update your workflow YAML files under .github/workflows/*.yml, for example:
env:
STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}🤖 Prompt for AI Agents
In frontend/src/utils/stripe.ts at line 6, you correctly use
process.env.STRIPE_SECRET_KEY for the Stripe client initialization, but your
GitHub Actions workflows do not currently include this environment variable. To
fix this, add STRIPE_SECRET_KEY as a repository secret in GitHub, then update
your workflow YAML files in .github/workflows/ to include STRIPE_SECRET_KEY in
the env section, setting it to ${{ secrets.STRIPE_SECRET_KEY }} so that the
Stripe client can access the secret key during CI runs.
Summary by CodeRabbit