Establish an e2e backend instance locally and in CI/CD #2429
Conversation
github-actions
bot
added
backend
docker
Summary by CodeRabbit
WalkthroughAdds end-to-end testing infrastructure: new Makefile e2e targets, an E2E docker-compose stack, example frontend/backend e2e env files, a composite GitHub Action to prepare the E2E environment, CI workflow adjustments to add a Postgres service and setup step, and minor Dockerfile/compose entrypoint/expose tweaks. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (5 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 |
![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
🧹 Nitpick comments (7)
docker-compose/backend.e2e.yaml (4)
16-22: Set DJANGO_SETTINGS_MODULE default for e2e.Make the e2e stack independent of dev/prod .env.
environment: + DJANGO_SETTINGS_MODULE: ${DJANGO_SETTINGS_MODULE:-settings.e2e} DJANGO_DB_HOST: ${DJANGO_DB_HOST:-db} DJANGO_DB_NAME: ${DJANGO_DB_NAME:-nest_db_e2e} DJANGO_DB_PASSWORD: ${DJANGO_DB_PASSWORD:-nest_user_e2e_password} DJANGO_DB_PORT: ${DJANGO_DB_PORT:-5432} DJANGO_DB_USER: ${DJANGO_DB_USER:-nest_user_e2e}
22-25: Add a backend healthcheck to enable compose --wait and reliable test gating.Without a healthcheck, CI can race the server startup.
ports: - 8000:8000 + healthcheck: + test: ["CMD-SHELL", "python -c 'import socket,time,sys; \ +for _ in range(30): \ + try: socket.create_connection((\"localhost\",8000),2).close(); sys.exit(0) \ + except OSError: time.sleep(1) \ +sys.exit(1)'"] + interval: 5s + timeout: 3s + retries: 10 + start_period: 10s
41-43: E2E DB volume persists across runs; add a clean target to avoid stale state.Persistent volume improves speed but harms repeatability. Add a Makefile clean target that runs
docker compose -p nest-e2e -f docker-compose/backend.e2e.yaml down -v.
17-21: Default DB creds committed (ok for test) — but prefer .env.e2e to avoid spreading defaults.Low risk, but moving these to an
.env.e2ekeeps compose cleaner and avoids accidental reuse.Also applies to: 29-33
backend/docker/Dockerfile.e2e (2)
23-24: Pin Poetry to a version for reproducible builds.Unpinned Poetry can break builds unexpectedly.
-RUN --mount=type=cache,target=${PIP_CACHE_DIR} \ - python -m pip install poetry --cache-dir ${PIP_CACHE_DIR} +RUN --mount=type=cache,target=${PIP_CACHE_DIR} \ + python -m pip install 'poetry==1.8.3' --cache-dir ${PIP_CACHE_DIR}
31-32: Install only runtime deps for a slimmer image.If dev deps exist, prefer:
poetry install --no-root --only main.- poetry install --no-root + poetry install --no-root --only mainbackend/Makefile (1)
14-20: Add a clean target for the e2e stack (containers + volume).Ensures repeatable runs and easy teardown.
clean-backend-docker: @docker container rm -f nest-backend >/dev/null 2>&1 || true @docker container rm -f nest-cache >/dev/null 2>&1 || true @docker container rm -f nest-db >/dev/null 2>&1 || true @docker image rm -f nest-local-backend >/dev/null 2>&1 || true @docker volume rm -f nest-local_backend-venv >/dev/null 2>&1 || true + +clean-backend-e2e-docker: + @docker compose --project-name nest-e2e -f docker-compose/backend.e2e.yaml down -v
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
backend/data/nest-e2e-data.sql.gzis excluded by!**/*.gz
📒 Files selected for processing (3)
backend/Makefile(4 hunks)backend/docker/Dockerfile.e2e(1 hunks)docker-compose/backend.e2e.yaml(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). (4)
- GitHub Check: Run frontend e2e tests
- GitHub Check: Run backend tests
- GitHub Check: Run frontend unit tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (2)
backend/Makefile (1)
84-87: load-data-e2e is fine as long as backend is healthy.No changes needed; verify it follows
run-backend-e2ein CI to avoid races.backend/docker/Dockerfile.e2e (1)
1-1: Ensure registry mirror sync and BuildKit enabled
python:3.13.7-alpineexists on Docker Hub—verify your mirror has this tag- CI environment didn’t expose BuildKit variables—enable BuildKit (
DOCKER_BUILDKIT=1) forRUN --mountsupport
github-actions
bot
added
ci
and removed
docker
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/run-ci-cd.yaml(1 hunks)backend/docker/Dockerfile(0 hunks)docker-compose/backend.e2e.yaml(1 hunks)docker-compose/production.yaml(1 hunks)docker-compose/staging.yaml(1 hunks)
💤 Files with no reviewable changes (1)
- backend/docker/Dockerfile
🚧 Files skipped from review as they are similar to previous changes (1)
- docker-compose/backend.e2e.yaml
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/run-ci-cd.yaml
188-188: unexpected key "environment" for "services" section. expected one of "credentials", "env", "image", "options", "ports", "volumes"
(syntax-check)
🔇 Additional comments (3)
docker-compose/production.yaml (1)
4-4: LGTM — verify entrypoint script exists in the backend image.The explicit entrypoint aligns with the backend Dockerfile changes and provides consistent startup across environments.
Confirm that
/home/owasp/entrypoint.shis present in the backend Docker image (backend/docker/Dockerfile context).docker-compose/staging.yaml (1)
4-4: LGTM — mirrors production entrypoint.Consistent with production.yaml and backend Dockerfile updates.
.github/workflows/run-ci-cd.yaml (1)
233-238: The e2e test data file is properly committed and available.The file
backend/data/nest-e2e-data.sql.gzis tracked in git (commit 4002a19) and present on the PR branch. The workflow will successfully access it during execution. No action needed.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/setup-e2e-environment/action.yaml (1)
9-9: Critical: Remove hardcoded database credentials and password from source code.Passwords and database credentials are hardcoded throughout this action (lines 9, 21, 23, 44–48), which is a security vulnerability. These must never be checked into source control. Additionally, hardcoding makes the action inflexible and difficult to reuse.
Add action inputs for all database parameters and consume them throughout:
+inputs: + db-host: + description: 'PostgreSQL host (e.g., db or localhost)' + required: false + default: 'localhost' + db-port: + description: 'PostgreSQL port' + required: false + default: '5432' + db-user: + description: 'PostgreSQL user' + required: false + default: 'nest_user_e2e' + db-name: + description: 'PostgreSQL database name' + required: false + default: 'nest_db_e2e' + db-password: + description: 'PostgreSQL password (pass via GitHub secret)' + required: true + runs: using: "composite" steps: - name: Wait for database to be ready run: | - until docker exec ${{ job.services.db.id }} pg_isready -U nest_user_e2e -d nest_db_e2e; do + until docker exec ${{ job.services.db.id }} pg_isready -U ${{ inputs.db-user }} -d ${{ inputs.db-name }}; do echo "Waiting for database..." sleep 5 done shell: bash - name: Load Postgres data env: - PGPASSWORD: nest_user_e2e_password + PGPASSWORD: ${{ inputs.db-password }} run: | - gunzip -c backend/data/nest-e2e.sql.gz | psql -h localhost -U nest_user_e2e -d nest_db_e2e + gunzip -c backend/data/nest-e2e.sql.gz | psql -h ${{ inputs.db-host }} -U ${{ inputs.db-user }} -d ${{ inputs.db-name }} -p ${{ inputs.db-port }} shell: bash - name: Start Backend in the background run: | docker run --rm --name nest-backend-e2e-runner \ --env-file backend/.env.example \ -e DJANGO_SETTINGS_MODULE=settings.test \ - -e DJANGO_DB_HOST=host.docker.internal \ - -e DJANGO_DB_NAME=nest_db_e2e \ - -e DJANGO_DB_USER=nest_user_e2e \ - -e DJANGO_DB_PASSWORD=nest_user_e2e_password \ - -e DJANGO_DB_PORT=5432 \ + -e DJANGO_DB_HOST=${{ inputs.db-host }} \ + -e DJANGO_DB_NAME=${{ inputs.db-name }} \ + -e DJANGO_DB_USER=${{ inputs.db-user }} \ + -e DJANGO_DB_PASSWORD=${{ inputs.db-password }} \ + -e DJANGO_DB_PORT=${{ inputs.db-port }} \ -p 8000:8000 \ owasp/nest:test-backend-e2e-latest \ sh -c ' python manage.py runserver 0.0.0.0:8000 ' shell: bashThen in
.github/workflows/run-ci-cd.yamlwhere this action is called, pass the secret:- name: Setup E2E environment uses: ./.github/workflows/setup-e2e-environment + with: + db-host: localhost + db-password: ${{ secrets.NEST_E2E_DB_PASSWORD }}Ensure
NEST_E2E_DB_PASSWORDis configured in your GitHub repository secrets.Also applies to: 21-21, 23-23, 44-48
🧹 Nitpick comments (1)
.github/workflows/setup-e2e-environment/action.yaml (1)
56-62: Enhance backend readiness check.The current check only verifies that the GraphQL endpoint responds (line 58). Consider validating the response structure to ensure the backend is truly ready to serve requests:
- name: Waiting for the backend to be ready run: | until curl -s http://localhost:8000/graphql -X POST \ -H "Content-Type: application/json" \ -d '{"query":"{__typename}"}' | grep -q '"data"'; do echo "Waiting for backend..." sleep 3 done echo "Backend is up!" shell: bashThis sends an actual GraphQL query and validates the response contains data, providing stronger assurance that the backend is functional.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/setup-e2e-environment/action.yaml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/setup-e2e-environment/action.yaml
1-1: "on" section is missing in workflow
(syntax-check)
1-1: "jobs" section is missing in workflow
(syntax-check)
2-2: unexpected key "description" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
4-4: unexpected key "runs" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
⏰ 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). (4)
- GitHub Check: Run Code Scan
- GitHub Check: Run CI Denendencies Scan
- GitHub Check: Run frontend e2e tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (1)
.github/workflows/setup-e2e-environment/action.yaml (1)
1-6: Note on static analysis warnings:The actionlint warnings about missing "on" and "jobs" sections are false positives. This is a composite GitHub Actions action (not a workflow), and the structure is correct. Composite actions require
name,description, andrunssections—not workflow-level keys. The file structure is valid. ✅
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/setup-e2e-environment/action.yaml (2)
15-17: Minor: Sudo may not be available in all runners.Line 16 uses
sudo apt-get installto installpostgresql-client. Some GitHub Actions runners may not have passwordless sudo enabled, or the package may already be present. Consider either:
- Removing sudo if the runner environment guarantees the package is pre-installed or privileged.
- Adding error handling or making the step conditional.
57-64: Weak backend readiness check.Line 59 polls
http://localhost:8000/graphqlbut only verifies thatcurlsucceeds (HTTP status 2xx or 3xx). A more robust check should validate:
- Specific HTTP status code (e.g., 200).
- Response contains expected content (e.g., GraphQL schema or query result).
- Backend is fully initialized (database connections ready, migrations applied).
Without this, the action may signal "ready" even if the backend is partially initialized.
Consider enhancing the readiness check:
- name: Waiting for the backend to be ready run: | until curl -s -f -w "%{http_code}" http://localhost:8000/graphql -o /dev/null | grep -q 200; do echo "Waiting for backend..." sleep 3 done echo "Backend is up!" shell: bashAlternatively, query the GraphQL endpoint with a simple introspection query to ensure the schema is loaded.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/setup-e2e-environment/action.yaml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/setup-e2e-environment/action.yaml
1-1: "on" section is missing in workflow
(syntax-check)
1-1: "jobs" section is missing in workflow
(syntax-check)
2-2: unexpected key "description" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
4-4: unexpected key "runs" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
⏰ 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). (2)
- GitHub Check: Run frontend e2e tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (1)
.github/workflows/setup-e2e-environment/action.yaml (1)
1-6: Metadata structure looks correct.The action is now properly defined as a composite action with top-level
name,description, andrunsfields. The metadata fix from the prior review was successfully applied.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
.github/workflows/setup-e2e-environment/action.yaml (3)
8-8: Major: Parameterize hardcoded database credentials.Lines 8, 22, and 45–48 hardcode database connection details (username, database name, host, port). While
localhoston line 44 is correct for GitHub Actions, these credentials should be configurable via action inputs rather than hardcoded. This approach:
- Allows reuse in different environments (local development, staging, production test instances).
- Enables override without code changes.
- Aligns with prior feedback on parameterization.
Add action inputs for all database credentials:
+inputs: + db-host: + description: "PostgreSQL host" + required: false + default: "localhost" + db-port: + description: "PostgreSQL port" + required: false + default: "5432" + db-user: + description: "PostgreSQL username" + required: false + default: "nest_user_e2e" + db-name: + description: "PostgreSQL database name" + required: false + default: "nest_db_e2e" + runs: using: "composite" steps: - name: Wait for database to be ready run: | - until docker exec ${{ job.services.db.id }} pg_isready -U nest_user_e2e -d nest_db_e2e; do + until docker exec ${{ job.services.db.id }} pg_isready -U ${{ inputs.db-user }} -d ${{ inputs.db-name }}; doThen replace all other hardcoded occurrences (lines 22, 45–48):
- gunzip -c backend/data/nest-e2e.sql.gz | psql -h localhost -U nest_user_e2e -d nest_db_e2e + gunzip -c backend/data/nest-e2e.sql.gz | psql -h ${{ inputs.db-host }} -U ${{ inputs.db-user }} -d ${{ inputs.db-name }}- -e DJANGO_DB_HOST=localhost \ - -e DJANGO_DB_NAME=nest_db_e2e \ - -e DJANGO_DB_USER=nest_user_e2e \ - -e DJANGO_DB_PASSWORD=nest_user_e2e_password \ - -e DJANGO_DB_PORT=5432 \ + -e DJANGO_DB_HOST=${{ inputs.db-host }} \ + -e DJANGO_DB_NAME=${{ inputs.db-name }} \ + -e DJANGO_DB_USER=${{ inputs.db-user }} \ + -e DJANGO_DB_PASSWORD=${{ inputs.db-password }} \ + -e DJANGO_DB_PORT=${{ inputs.db-port }} \Also applies to: 22-22, 45-48
20-20: Critical security risk: Hardcoded database password in source control.Passwords must never be committed to source code, even for test-only environments. Line 20 embeds
nest_user_e2e_passworddirectly. This was flagged in multiple past review comments and remains unresolved.The password should be passed via GitHub secrets. Add an action input for the password and reference the secret from the caller workflow:
+inputs: + db-password: + description: "Database password (use GitHub secret)" + required: true + runs: using: "composite" steps: - name: Load Postgres data env: - PGPASSWORD: nest_user_e2e_password + PGPASSWORD: ${{ inputs.db-password }} run: |Then update the caller in
.github/workflows/run-ci-cd.yamlto pass:with: db-password: ${{ secrets.NEST_E2E_DB_PASSWORD }}Ensure
NEST_E2E_DB_PASSWORDis added to GitHub repository secrets.
4-5: Critical: Missingusing: "composite"in runs block.GitHub Actions composite actions require the
using: "composite"directive. The current syntax is invalid and will fail when executed. This was flagged in prior reviews and appears to remain unresolved.Add the missing
using:directive:runs: + using: "composite" steps:
🧹 Nitpick comments (2)
.github/workflows/setup-e2e-environment/action.yaml (2)
15-16: Conditional platform support: PostgreSQL client installation may fail on non-Debian runners.Line 15 uses
apt-get, which is specific to Debian/Ubuntu-based systems. If this action runs on a macOS or Windows GitHub-hosted runner, or a custom runner with a different package manager, installation will fail.Add a platform check or consider installing the client conditionally within the specific step that needs it. Alternatively, if this action is only intended for Linux runners, add documentation or a runner label constraint.
- name: Install PostgreSQL client + if: runner.os == 'Linux' run: sudo apt-get install -y postgresql-client shell: bash
38-54: Consider error handling and logging for background service startup.The backend container is started in the background without explicit error checking. If the container fails to start (e.g., due to missing image, port conflict, or startup errors), the action will not immediately detect the failure—it will only discover it later during the readiness check at line 56–63.
Capture container startup output for debugging:
- name: Start Backend in the background run: | - docker run --rm --name nest-backend-e2e-runner \ + nohup docker run --rm --name nest-backend-e2e-runner \ --env-file backend/.env.example \ --network host \ -e DJANGO_SETTINGS_MODULE=settings.test \ -e DJANGO_DB_HOST=localhost \ -e DJANGO_DB_NAME=nest_db_e2e \ -e DJANGO_DB_USER=nest_user_e2e \ -e DJANGO_DB_PASSWORD=nest_user_e2e_password \ -e DJANGO_DB_PORT=5432 \ -p 8000:8000 \ owasp/nest:test-backend-e2e-latest \ sh -c ' python manage.py runserver 0.0.0.0:8000 - ' + ' > /tmp/backend-e2e.log 2>&1 & + sleep 2 # Give container time to initializeThis captures logs in
/tmp/backend-e2e.logfor inspection if the readiness check fails. Additionally, increase the timeout or add retry logic to the readiness check (lines 56–63) if backend startup is slow.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/setup-e2e-environment/action.yaml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/setup-e2e-environment/action.yaml
1-1: "on" section is missing in workflow
(syntax-check)
1-1: "jobs" section is missing in workflow
(syntax-check)
2-2: unexpected key "description" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
4-4: unexpected key "runs" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
⏰ 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). (3)
- GitHub Check: Run CI Denendencies Scan
- GitHub Check: Run Code Scan
- GitHub Check: CodeQL (javascript-typescript)
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
.github/workflows/setup-e2e-environment/action.yaml (2)
9-25: 🔴 CRITICAL: Hardcoded database password and credentials in source code — unresolved from prior reviews.Line 21 embeds the plaintext database password
nest_user_e2e_passworddirectly in the workflow, and lines 9, 23 hardcode all database credentials (username, database name, host). This is a security vulnerability regardless of whether these are test-only credentials. Passwords and API keys must never be hardcoded in workflows; use GitHub Secrets instead. For composite actions, secrets must be passed via action inputs.Prior review comments (dated around commits 3376a65–d054d25) flagged this exact issue with a comprehensive solution using action inputs and parameterization. That guidance remains valid and unresolved. Implement the suggested fix from those comments before merging:
- Add
inputssection to the action metadata defining:db-user,db-name,db-host,db-port,db-password(all with sensible defaults except password).- Replace hardcoded credentials with
${{ inputs.db-user }}, etc. throughout this step and the backend startup step.- Update the caller workflow (run-ci-cd.yaml) to pass credentials via
with:and${{ secrets.NEST_E2E_DB_PASSWORD }}.- Create a GitHub repository secret for
NEST_E2E_DB_PASSWORDin the repository settings.Verify that the caller workflow (run-ci-cd.yaml) has been updated to pass the parameterized inputs before this action is merged.
39-55: Improvement: Remove hardcoded database credentials from Docker environment variables (repeated critical issue).Lines 46–49 repeat the hardcoded credentials problem. Once the action inputs are parameterized (per the prior critical comment), replace these hardcoded
-eflags with the parameterized versions:- -e DJANGO_DB_HOST=localhost \ - -e DJANGO_DB_NAME=nest_db_e2e \ - -e DJANGO_DB_USER=nest_user_e2e \ - -e DJANGO_DB_PASSWORD=nest_user_e2e_password \ + -e DJANGO_DB_HOST=${{ inputs.db-host }} \ + -e DJANGO_DB_NAME=${{ inputs.db-name }} \ + -e DJANGO_DB_USER=${{ inputs.db-user }} \ + -e DJANGO_DB_PASSWORD=${{ inputs.db-password }} \Note: Line 45 correctly uses
localhost, which is appropriate for--network hoston GitHub Actions.Also, add a timeout to the subsequent health check loop (lines 57–64) to prevent indefinite waiting if the backend fails to start.
🧹 Nitpick comments (1)
.github/workflows/setup-e2e-environment/action.yaml (1)
57-64: Add timeout to backend readiness loop to prevent indefinite waiting.The curl polling approach is reasonable, but lacks a timeout mechanism. If the backend fails to start, the workflow will hang indefinitely. Add a counter and exit condition:
- name: Waiting for the backend to be ready run: | + max_attempts=60 + attempt=0 until curl -s http://localhost:8000/graphql > /dev/null; do + attempt=$((attempt + 1)) + if [ $attempt -ge $max_attempts ]; then + echo "Backend failed to start after $max_attempts attempts" + exit 1 + fi echo "Waiting for backend..." sleep 3 done echo "Backend is up!" shell: bash
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/setup-e2e-environment/action.yaml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/setup-e2e-environment/action.yaml
1-1: "on" section is missing in workflow
(syntax-check)
1-1: "jobs" section is missing in workflow
(syntax-check)
2-2: unexpected key "description" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
4-4: unexpected key "runs" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
⏰ 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). (4)
- GitHub Check: Run Code Scan
- GitHub Check: Run CI Denendencies Scan
- GitHub Check: Run frontend e2e tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (2)
.github/workflows/setup-e2e-environment/action.yaml (2)
1-6: Action metadata structure is correct.The composite action structure is properly defined with name, description, and runs/using/steps. Static analysis hints about missing "on" and "jobs" sections are false positives—these are not required in composite actions.
26-37: Good: Backend Docker image build configuration.The docker/build-push-action setup uses GHA cache and specifies proper context/platform/tags. This is appropriate.
github-actions
bot
added
docs
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
.github/workflows/setup-e2e-environment/action.yaml (2)
9-9: Critical: Hardcoded database credentials must be parameterized.Database credentials (username, database name) are hardcoded in the
pg_isreadycommand. These should be accepted as action inputs to allow flexibility and avoid embedding credentials in source control.Based on prior unresolved feedback, add action inputs:
+inputs: + db-user: + description: 'PostgreSQL user for e2e environment' + required: false + default: 'nest_user_e2e' + db-name: + description: 'PostgreSQL database name for e2e environment' + required: false + default: 'nest_db_e2e' + db-password: + description: 'PostgreSQL password (use GitHub secret)' + required: true + runs: using: 'composite' steps: - name: Wait for database to be ready run: | - until docker exec ${{ job.services.db.id }} pg_isready -U nest_user_e2e -d nest_db_e2e; do + until docker exec ${{ job.services.db.id }} pg_isready -U ${{ inputs.db-user }} -d ${{ inputs.db-name }}; do
19-24: Critical: Remove hardcoded database password.Line 21 embeds the database password
nest_user_e2e_passwordin source control. This is a security vulnerability—passwords must never be committed to a repository, even for testing.Use the
db-passwordinput from the previous suggestion:- name: Load Postgres data env: - PGPASSWORD: nest_user_e2e_password + PGPASSWORD: ${{ inputs.db-password }} run: | - gunzip -c backend/data/nest-e2e.sql.gz | psql -h localhost -U nest_user_e2e -d nest_db_e2e + gunzip -c backend/data/nest-e2e.sql.gz | psql -h localhost -U ${{ inputs.db-user }} -d ${{ inputs.db-name }}Then update the calling workflow to pass the secret:
- name: Setup E2E environment uses: ./.github/workflows/setup-e2e-environment with: db-user: nest_user_e2e db-name: nest_db_e2e db-password: ${{ secrets.NEST_E2E_DB_PASSWORD }}Ensure
NEST_E2E_DB_PASSWORDis added to GitHub repository secrets.backend/Makefile (1)
64-66: Critical: Shell redirection in CMD variable will not execute correctly.The pipeline with
|and>in the CMD variable will not be interpreted properly by Make. The redirection occurs inside the container's context, and the shell metacharacters may not expand as expected. Theexec-db-e2e-commandtarget passes CMD todocker exec, but the redirection should happen on the host side.Run the dump pipeline from the host:
dump-data-e2e: @echo "Dumping Nest e2e data" - @CMD="pg_dumpall -U nest_user_e2e --clean | gzip -9 > backend/data/nest-e2e.sql.gz" $(MAKE) exec-db-e2e-command + @mkdir -p backend/data + @docker exec -i nest-db-e2e pg_dumpall -U nest_user_e2e --clean | gzip -9 > backend/data/nest-e2e.sql.gzNote: Removed
-tto avoid TTY artifacts in the dump, and removed-hto use the local socket.
🧹 Nitpick comments (2)
.github/workflows/setup-e2e-environment/action.yaml (2)
39-50: Backend startup mixes env file with explicit overrides.Line 42 loads
backend/.env.e2e.examplebut line 44 explicitly overridesDJANGO_DB_HOST=localhost. If the env file already contains the correct values, the explicit override is redundant. If different values are needed, consider accepting them as action inputs for flexibility.Consider accepting database connection parameters as inputs and removing the hardcoded override, or document why
DJANGO_DB_HOSTmust be overridden despite using an env file.
52-59: Use curl instead of wget for consistency.Based on previous feedback noting "wget/curl inconsistent usage", consider standardizing on one tool. The codebase may prefer
curlfor HTTP checks.- name: Waiting for the backend to be ready run: | - until wget --spider http://localhost:8000/a; do + until curl -f -s http://localhost:8000/a > /dev/null; do echo "Waiting for backend..." sleep 3 done
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.github/workflows/setup-e2e-environment/action.yaml(1 hunks).gitignore(1 hunks)backend/.env.e2e.example(1 hunks)backend/Makefile(4 hunks)backend/apps/common/utils.py(1 hunks)backend/settings/base.py(1 hunks)backend/settings/e2e.py(1 hunks)docker-compose/e2e.yaml(1 hunks)frontend/.env.e2e.example(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- docker-compose/e2e.yaml
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 2429
File: backend/Makefile:30-32
Timestamp: 2025-10-26T12:50:50.512Z
Learning: The `exec-backend-e2e-command` and `exec-db-e2e-command` Makefile targets in the backend/Makefile are intended for local development and debugging only, not for CI/CD execution, so the `-it` flags are appropriate.
📚 Learning: 2025-10-26T12:50:50.512Z
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 2429
File: backend/Makefile:30-32
Timestamp: 2025-10-26T12:50:50.512Z
Learning: The `exec-backend-e2e-command` and `exec-db-e2e-command` Makefile targets in the backend/Makefile are intended for local development and debugging only, not for CI/CD execution, so the `-it` flags are appropriate.
Applied to files:
backend/Makefile
🧬 Code graph analysis (1)
backend/settings/e2e.py (1)
backend/settings/base.py (1)
Base(9-213)
🪛 actionlint (1.7.8)
.github/workflows/setup-e2e-environment/action.yaml
1-1: "on" section is missing in workflow
(syntax-check)
1-1: "jobs" section is missing in workflow
(syntax-check)
2-2: unexpected key "description" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
4-4: unexpected key "runs" for "workflow" section. expected one of "concurrency", "defaults", "env", "jobs", "name", "on", "permissions", "run-name"
(syntax-check)
🪛 dotenv-linter (4.0.0)
frontend/.env.e2e.example
[warning] 15-15: [UnorderedKey] The NEXTAUTH_SECRET key should go before the NEXT_PUBLIC_API_URL key
(UnorderedKey)
[warning] 16-16: [UnorderedKey] The NEXTAUTH_URL key should go before the NEXT_PUBLIC_API_URL key
(UnorderedKey)
backend/.env.e2e.example
[warning] 8-8: [UnorderedKey] The DJANGO_CONFIGURATION key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 9-9: [UnorderedKey] The DJANGO_DB_HOST key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 10-10: [UnorderedKey] The DJANGO_DB_NAME key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 11-11: [UnorderedKey] The DJANGO_DB_USER key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 12-12: [UnorderedKey] The DJANGO_DB_PASSWORD key should go before the DJANGO_DB_USER key
(UnorderedKey)
[warning] 13-13: [UnorderedKey] The DJANGO_DB_PORT key should go before the DJANGO_DB_USER key
(UnorderedKey)
[warning] 14-14: [UnorderedKey] The DJANGO_OPEN_AI_SECRET_KEY key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 15-15: [QuoteCharacter] The value has quote characters (', ")
(QuoteCharacter)
[warning] 15-15: [UnorderedKey] The DJANGO_PUBLIC_IP_ADDRESS key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 16-16: [UnorderedKey] The DJANGO_REDIS_HOST key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 17-17: [UnorderedKey] The DJANGO_REDIS_PASSWORD key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 18-18: [UnorderedKey] The DJANGO_RELEASE_VERSION key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 19-19: [UnorderedKey] The DJANGO_SECRET_KEY key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
[warning] 20-20: [UnorderedKey] The DJANGO_SENTRY_DSN key should go before the DJANGO_SETTINGS_MODULE key
(UnorderedKey)
🔇 Additional comments (6)
.gitignore (1)
9-9: LGTM!The change correctly unignores
.env.e2e.examplefiles, following the same pattern as the existing.env.exampleunignore rule on line 8.frontend/.env.e2e.example (1)
1-16: LGTM!The e2e example environment file is well-structured with appropriate placeholder values for local testing. The localhost URLs and placeholder secrets are suitable for an example file that developers will copy and customize.
backend/settings/base.py (1)
22-22: LGTM!The new
IS_E2E_ENVIRONMENTflag follows the established pattern of other environment indicators (lines 23-26) and provides a clean way to detect e2e testing contexts throughout the application.backend/Makefile (1)
116-118: Running in foreground may block in CI contexts.The
docker compose upcommand runs in the foreground with--abort-on-container-exit. While suitable for local development (where blocking is expected), this would block CI pipelines if this target is ever used in automation.Verify whether this target will be invoked by CI/CD pipelines. If yes, consider adding a detached variant:
run-backend-e2e-detached: @DOCKER_BUILDKIT=1 \ docker compose --project-name nest-e2e -f docker-compose/e2e.yaml up -d --build --wait --remove-orphans backend dbIf this target is strictly for local development, document that in a comment.
backend/apps/common/utils.py (1)
98-98: LGTM!The updated logic correctly treats e2e environments like local environments for IP address resolution. In both cases, returning
PUBLIC_IP_ADDRESSis appropriate since the request context won't have production-like forwarding headers.backend/settings/e2e.py (1)
1-23: LGTM with observation: Consider whether disabling all logging is intentional.The E2E configuration is well-structured and correctly sets
IS_E2E_ENVIRONMENT = True(line 21) andDEBUG = False(line 20) for production-like testing. The CORS and CSRF origins appropriately cover both Docker service names and localhost URLs.However, line 22 sets
LOGGING = {}, which completely disables the logging configuration inherited fromBase(Base.LOGGING includes console handler and django logger). This may make debugging e2e test failures more difficult.Verify whether completely disabling logging is intentional for e2e tests. If test output needs to remain clean, consider setting log levels to WARNING/ERROR rather than removing all logging configuration:
LOGGING = { "version": 1, "disable_existing_loggers": False, "handlers": { "console": { "level": "WARNING", "class": "logging.StreamHandler", }, }, "loggers": { "django": { "handlers": ["console"], "level": "WARNING", }, }, }
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/.env.e2e.example (1)
1-16: Consider adding inline comments or a header explaining the e2e environment setup.This example file would benefit from a brief comment block explaining its purpose and which variables are critical for the e2e tests to function. This aligns with the PR objective to "provide documentation explaining how to use the new test environment."
Example header:
+# E2E Testing Environment Configuration +# This file defines environment variables for end-to-end and integration tests. +# Copy this file to .env.e2e and update placeholders (GitHub OAuth, NEXTAUTH_SECRET). +# Backend must be running on port 8001 for tests to work. + NEXT_PUBLIC_API_URL=http://localhost:8001/
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
CONTRIBUTING.md(1 hunks)backend/Makefile(4 hunks)backend/settings/e2e.py(1 hunks)docker-compose/e2e.yaml(1 hunks)frontend/.env.e2e.example(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- backend/Makefile
- CONTRIBUTING.md
- docker-compose/e2e.yaml
- backend/settings/e2e.py
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 2429
File: backend/Makefile:30-32
Timestamp: 2025-10-26T12:50:50.512Z
Learning: The `exec-backend-e2e-command` and `exec-db-e2e-command` Makefile targets in the backend/Makefile are intended for local development and debugging only, not for CI/CD execution, so the `-it` flags are appropriate.
🪛 dotenv-linter (4.0.0)
frontend/.env.e2e.example
[warning] 15-15: [UnorderedKey] The NEXTAUTH_SECRET key should go before the NEXT_PUBLIC_API_URL key
(UnorderedKey)
[warning] 16-16: [UnorderedKey] The NEXTAUTH_URL key should go before the NEXT_PUBLIC_API_URL key
(UnorderedKey)
⏰ 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). (4)
- GitHub Check: Run frontend e2e tests
- GitHub Check: Run frontend unit tests
- GitHub Check: Run backend tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (2)
frontend/.env.e2e.example (2)
3-3: Verify the environment label for e2e tests.
NEXT_PUBLIC_ENVIRONMENT=localmay be semantically misleading for e2e testing context. Consider whether this should be set to"e2e"to clearly distinguish end-to-end test runs from local development, which could be important for conditional logic or analytics/monitoring.
1-4: Port and environment configuration verified as correct.All backend endpoints in
frontend/.env.e2e.examplecorrectly targethttp://localhost:8001, which aligns with the docker-compose e2e setup (docker-compose/e2e.yamlport mapping8001:8000). TheNEXT_PUBLIC_ENVIRONMENT=localsetting is intentionally configured for e2e tests, as confirmed by the Makefile and its usage innext.config.ts.
2 participants
Proposed change
Resolves #2422
Add the PR description here.
Checklist
make check-testlocally; all checks and tests passed.