Stage

[evereq]

Description

Please include a summary of the changes and the related issues.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented on my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

Previous screenshots

Please add here videos or images of the previous status

Current screenshots

Please add here videos or images of the current (new) status

To fix the issue, the workflow should explicitly set the minimum required permissions for the GITHUB_TOKEN used by the workflow. This is done by adding a permissions block to either the root of the workflow or specifically to the job in question. Since the workflow does not interact with repository content in a way that requires write access and only needs to read the repo (e.g., checkout code), the minimal required permission is contents: read.

The best way to fix is to add a top-level permissions block beneath the workflow name and before the jobs definition. This change limits the actions that can be performed with the GITHUB_TOKEN, improving security by following the principle of least privilege. No imports, methods, or additional code changes are needed: only the addition of the permissions YAML block.

---

To fix the problem, add a top-level permissions block in .github/workflows/docker-build-publish-api.yaml to restrict the permissions granted to the GITHUB_TOKEN for this workflow. The appropriate permission for code checkout and reading sources is contents: read, which is the minimum recommended. Unless specific workflow steps require additional write permissions to repository resources (such as issues, PRs, or packages), avoid granting them. In this file, no steps require such additional permissions—the authentication to the package registries and Docker Hub uses explicit credentials. Therefore, add:

permissions:
  contents: read

after the workflow name: but before the jobs are defined (typically after line 2).
No imports or new libraries are needed.

---

The best way to fix this issue is to add a permissions block at the root of the workflow YAML file (.github/workflows/docker-build-publish-portal-dev.yaml). This block must declare the least privilege required for the workflow to operate successfully. Since the workflow's steps primarily interact with external services using secrets and do not write to the repository, contents: read is sufficient. Add this block immediately after the name and before on.

• Modify .github/workflows/docker-build-publish-portal-dev.yaml
• Insert:

  permissions:
    contents: read

  right after the name: field (ideally before the on: block).
• No additional imports, methods, or definitions are needed.

---

To fix the problem, add a permissions: block to the workflow, either at the workflow (root) level—applying to all jobs—or at the individual job level—customizing permissions per job. Since the workflow pushes images (requiring only contents: read for basic checkout/build actions and possibly some permission for packages if publishing to the GitHub Container Registry), but does not appear to need write access to repository content or issues/pull-requests, the least-privilege approach is to set contents: read at the minimum. If in the future you use steps that require more permissions, you can expand the permissions block.

How to fix:

• Add a permissions key right below the name field at the root of the workflow YAML file (recommended for one-job workflows), set to contents: read.
• This fix will restrict the GITHUB_TOKEN to read-only for repository contents and will prevent write operations unless explicitly expanded.
• No new imports or dependencies are required; it's a configuration change only.

File/region to change:

• Edit .github/workflows/docker-build-publish-portal.yaml
• Insert the following block after the name: property.

---

[greptile-apps]

Greptile Overview

Greptile Summary

This PR consolidates infrastructure improvements and bug fixes across deployment configurations. The changes migrate from Traefik to nginx ingress controller, fix critical typos in deployment automation, and add the REC_JWT_SECRET environment variable.

Major Changes:

• Migrated Kubernetes ingress from Traefik to nginx ingress controller in both dev and prod manifests
• Fixed critical typo: NEXT_PUBLIC_EXTENTION_REDIRECT_URL → NEXT_PUBLIC_EXTENSION_REDIRECT_URL across Dockerfile, workflows, and env samples
• Fixed deployment command typo: ever-rec-poral-* → ever-rec-portal-* in deploy workflows
• Added REC_JWT_SECRET environment variable to both dev and prod API deployments
• Added TLS secret generation step to deployment workflows
• Prefixed dev environment secrets with DEV_ prefix for better separation
• Changed production container registry from GitHub to DigitalOcean registry
• Standardized YAML formatting across all workflow files

Infrastructure Impact:
The ingress controller migration requires nginx ingress controller to be installed in the Kubernetes cluster. The TLS secrets are now generated dynamically during deployment from GitHub secrets.

Confidence Score: 4/5

• Safe to merge with one minor workflow naming issue
• The changes are well-structured infrastructure improvements with proper typo fixes. Only issue is the incorrect workflow name in deploy-do-prod.yml (says "Dev" instead of "Prod"), which is cosmetic but should be fixed for clarity. All other changes are solid improvements.
• .github/workflows/deploy-do-prod.yml needs workflow name correction

Important Files Changed

File Analysis

Filename	Score	Overview
.github/workflows/deploy-do-prod.yml	4/5	Fixed typo in deployment command, added TLS secret generation, added REC_JWT_SECRET env var. Has incorrect workflow name (says "Dev" instead of "Prod").
.github/workflows/deploy-do-dev.yml	5/5	Fixed typo in deployment command (ever-rec-poral-dev → ever-rec-portal-dev), added TLS secret generation, added REC_JWT_SECRET environment variable.
.deploy/k8s/k8s-manifest.dev.yaml	5/5	Migrated from Traefik to nginx ingress controller, improved YAML formatting, removed standalone Middleware resource, added REC_JWT_SECRET env var.
.deploy/k8s/k8s-manifest.prod.yaml	5/5	Migrated from Traefik to nginx ingress controller, improved YAML formatting, changed container images to DigitalOcean registry, added REC_JWT_SECRET env var.
.deploy/portal/Dockerfile	5/5	Fixed typo: NEXT_PUBLIC_EXTENTION_REDIRECT_URL → NEXT_PUBLIC_EXTENSION_REDIRECT_URL throughout the Dockerfile.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant DockerHub as Docker Hub
    participant DO as DigitalOcean Registry
    participant GHCR as GitHub Container Registry
    participant K8s as Kubernetes Cluster
    participant Nginx as Nginx Ingress
    participant App as Applications

    Note over GH: On push to develop/main
    GH->>GH: Build Docker Images
    GH->>DockerHub: Push images
    GH->>DO: Push images
    GH->>GHCR: Push images
    
    Note over GH: Deploy workflow triggered
    GH->>K8s: Generate TLS Secrets
    Note right of K8s: Decode base64 certs<br/>Create k8s secrets
    GH->>K8s: Apply manifests with envsubst
    Note right of K8s: Inject REC_JWT_SECRET<br/>and Firebase config
    GH->>K8s: Rollout restart deployments
    K8s->>DO: Pull latest images
    K8s->>App: Deploy API & Portal
    
    Note over Nginx,App: Ingress Configuration
    Nginx->>App: Route traffic with TLS
    Note right of Nginx: Uses nginx controller<br/>(migrated from Traefik)

Loading

Additional Comments (1)

1. .github/workflows/deploy-do-prod.yml, line 1 (link)

   syntax: workflow name says "Dev" but this is production

_{10 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}