fix(ci): use --no-engine for prisma validate in docker run

[itsmiso-ai]

Refs #249

Prisma CLI validate throws when DATABASE_URL is unset in production mode, even with --no-engine. Since the runner stage has NODE_ENV=production and no DATABASE_URL is available in the validate step, bypass the engine entirely with --no-engine.

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

PR #265 Review: fix(ci): use --no-engine for prisma validate in docker run

Summary

This PR fixes a CI failure in the Docker image build workflow where prisma validate was throwing because DATABASE_URL is unavailable in the runner stage (which has NODE_ENV=production) during the validation step.

Change-by-Change Findings

1. .github/workflows/image.yaml

   • Removed --env DATABASE_URL=postgresql://localhost:5432/dispatch from the prisma validate docker run command
   • Added --no-engine flag to bypass the Prisma engine entirely
   • This allows validation without requiring a live database connection
   • Source: PR body explains this directly: "bypass the engine entirely with --no-engine"

2. Dockerfile

   • Added ENV DATABASE_URL=postgresql://localhost:5432/dispatch in the builder stage
   • This ensures npx prisma generate can run during build
   • Sets a placeholder for runtime; actual DATABASE_URL should be injected at deployment
   • Source: Consistent with PR goal — provides default URL for build-time prisma operations

3. prisma.config.ts

   • Changed error check to if (process.env.NODE_ENV === "production" && !databaseUrl) — only throws in production
   • Added fallback: url: databaseUrl ?? "postgresql://localhost:5432/dispatch"
   • This allows the config to work in development without requiring DATABASE_URL
   • Source: Consistent with the overall fix pattern — reduces strictness for non-production environments

4. src/lib/prisma.ts

   • Applied same pattern: only throws error if NODE_ENV === "production" and DATABASE_URL is unset
   • Uses process.env.DATABASE_URL! with non-null assertion (runtime check guards it)
   • Source: Consistent with prisma.config.ts changes

Standards Compliance

• ✅ Code standards followed: error handling uses throw with meaningful messages
• ✅ No secrets committed: uses placeholder URL, not real credentials
• ✅ Consistent with Docker conventions: ENV for default values, injected at runtime
• ✅ CI workflow modified correctly with proper docker flags

Linked Issue Fit

• PR body references "#249" but no linked issue was provided in corpus
• The commit message and branch name reference "fix-253" — looking at git history, #253 ("remove hardcoded database credentials from prisma config") was merged into main (dbd224f) and this PR appears to be a follow-up addressing the CI validation step that was still failing even after the #253 fix
• The changes directly address the problem described: Prisma CLI validate throwing when DATABASE_URL is unset in production mode with --no-engine

Evidence Provider Findings

• No evidence providers configured for this PR

Tool Harness Findings

• No tool harness output provided

Unknowns / Needs Verification

• None identified — all changes are clear and internally consistent

Recommendation

Approve. The PR correctly uses --no-engine flag for CI validation and ensures DATABASE_URL is properly set in the Dockerfile builder stage. The pattern of only throwing errors in production (NODE_ENV === "production") and providing fallback URLs in non-production is consistent across all modified files. The changes follow repository conventions and are minimal and targeted.

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

PR Review: fix(ci): use --no-engine for prisma validate in docker run

Recommendation: Approve

This PR resolves a Docker image build failure caused by prisma validate requiring a database connection in production mode. The changes are targeted, minimal, and solve the stated problem.

Change-by-Change Findings

1. .github/workflows/image.yaml (+2/-2)

• Added --no-engine flag to prisma validate command
• This bypasses the Prisma query engine, preventing the CLI from attempting a database connection during validation
• Consistent with GitHub Actions CI conventions in this repository (per AGENTS.md: "Lint/typecheck blocks CI; must pass")

2. Dockerfile (+1/-0)

• Added ENV DATABASE_URL=postgresql://localhost:5432/dispatch in the builder stage
• Provides a fallback DATABASE_URL for build-time operations that need it (e.g., npx prisma generate)

3. prisma.config.ts (+2/-2)

• Changed environment check from unconditional to NODE_ENV === "production" only
• In non-production environments (development), the config now works without requiring DATABASE_URL
• Added nullish coalescing fallback (?? "postgresql://localhost:5432/dispatch") for the datasource URL

4. src/lib/prisma.ts (+2/-4)

• Changed check to only throw in production when DATABASE_URL is missing
• Removed intermediate databaseUrl variable; uses process.env.DATABASE_URL! directly with non-null assertion
• Follows the error handling pattern from AGENTS.md Code Standards ("provide meaningful error messages")

Standards Compliance

• ✅ Error handling: Error messages are preserved and provide context about missing DATABASE_URL
• ✅ CI conventions: GitHub Actions workflow changes follow established patterns
• ✅ No secrets committed: No .env files or sensitive values hardcoded; DATABASE_URL uses a local fallback value
• ✅ Prisma best practices: Changes align with the repository's Prisma usage (AGENTS.md: "Ensure npx prisma generate has run during build")

Linked Issue Fit

• PR body references "Refs #249" but no linked issue was found in corpus
• The PR description clearly states the problem: "Prisma CLI validate throws when DATABASE_URL is unset in production mode, even with --no-engine"
• The solution (adding --no-engine) directly addresses the stated issue

Unknowns / Needs Verification

• Issue #249 was referenced but not available in corpus for validation against acceptance criteria
• No tests were modified or added for the environment variable behavior changes

Evidence Provider Findings

No evidence providers were configured for this review.

Tool Harness Findings

No tool harness output was available for this review.

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

PR Review: Request Changes

Summary

This PR attempts to fix a Prisma CLI validate failure in Docker builds when DATABASE_URL is unset. However, the implementation has critical gaps that likely won't resolve the reported issue.

Change-by-Change Findings

1. .github/workflows/image.yaml (+1/-1)

• Whitespace change removing final newline. Likely unintentional/noise.

2. Dockerfile (+1/-0)

• Added: ENV DATABASE_URL=postgresql://localhost:5432/dispatch after npx prisma generate
• Critical Issue: This ENV instruction is in the builder stage (before FROM base AS runner). It does NOT propagate to the runner stage. If the Prisma validate issue occurs in the runner stage (as implied by "docker run"), this change has no effect there.

3. prisma.config.ts (+2/-2)

• Changed validation check from unconditional to if (process.env.NODE_ENV === "production" && !databaseUrl)
• Added fallback URL: url: databaseUrl ?? "postgresql://localhost:5432/dispatch"
• Concern: Hardcoded fallback connection string. Repository convention prohibits committing hardcoded credentials.

4. src/lib/prisma.ts (+2/-4)

• Changed validation check to if (process.env.NODE_ENV === "production" && !process.env.DATABASE_URL)
• Uses process.env.DATABASE_URL! with non-null assertion for adapter
• Concern: The fallback URL pattern from prisma.config.ts may not propagate to runtime PrismaClient initialization.

Standards Compliance

• ⚠️ Secrets/Credentials: Repository standard states "Never commit .env files, node_modules, .next, or build output." The hardcoded postgresql://localhost:5432/dispatch in prisma.config.ts introduces a fallback credential value. While it's not a real credential, it establishes a pattern of fallback URLs that could be problematic.
• ⚠️ Error handling: Uses error instanceof Error pattern appropriately in validation.

Linked Issue Fit

• No linked issue context was provided in the corpus. The PR body references "#249" but the issue content was not available for comparison.
• The PR title mentions "use --no-engine for prisma validate" but the diff contains no --no-engine flag changes in the workflow or Dockerfile.

Evidence Provider Findings

• No evidence providers configured.

Tool Harness Findings

• No tool harness output provided.

Unknowns / Needs Verification

1. Dockerfile stage scope: The ENV DATABASE_URL is set in the builder stage. Confirm whether the Prisma validate failure occurs in builder or runner. If runner, this change is ineffective.
2. No --no-engine flag: The PR title references --no-engine but no such flag appears in any workflow file. The git log shows commit f60bfc5 explicitly "remove unsupported --no-engine from prisma validate" — verify the intended fix approach.
3. Hardcoded fallback: The postgresql://localhost:5432/dispatch fallback URL in prisma.config.ts may be intentional for non-production builds but should be documented.
4. Issue #249: The linked issue content was not available. Cannot verify if this PR fully addresses the original problem.

Recommendation

Request changes — the Dockerfile change appears ineffective for the runner stage, and the PR title does not match the implementation (no --no-engine flag found). Please verify the fix targets the correct Docker stage and clarify the --no-engine discrepancy.

[itsmiso-ai]

Thanks for the review — addressing each concern:

1. Dockerfile stage scope

The ENV DATABASE_URL in the builder stage is specifically for npm run build (Next.js static generation reads it at build time). This does NOT carry over to the runner stage, which is intentional:

• Builder stage: Has DATABASE_URL so npm run build and npx prisma generate succeed during Docker build.
• Runner stage: Does NOT have DATABASE_URL. Production code (src/lib/prisma.ts:6) throws if DATABASE_URL is missing in production mode — this is the desired behavior for the runtime container.
• CI validate step: Passes --env DATABASE_URL=... at docker run time, independent of the Dockerfile ENV. This is why it works.

The CI workflow comment now documents this distinction (commit 1449282).

2. --no-engine flag removed

Correct — --no-engine was never a valid prisma validate flag in Prisma 7.x. It was removed in commit f60bfc5. The actual fix is simply passing DATABASE_URL via --env at docker run time so prisma.config.ts can load without errors.

3. Hardcoded fallback URL

Documented in prisma.config.ts:14-16 (commit 1449282). The fallback postgresql://localhost:5432/dispatch is intentional for dev/CI environments where no real database is needed (e.g., prisma generate, prisma validate). Production requires DATABASE_URL via the check at line 5.

4. Issue #249

The original problem: CI was failing because prisma validate could not load prisma.config.ts when DATABASE_URL was unset. The fix ensures:

• Dev/CI: fallback URL allows prisma CLI to work without a real DB
• Production: DATABASE_URL is required, with a clear error message if missing
• CI workflows: all pass DATABASE_URL via env vars

Updated PR description:

Fix Prisma validate failing when DATABASE_URL is unset.

Problem:
- `prisma validate` in CI fails because prisma.config.ts tries to use DATABASE_URL
- Production code requires DATABASE_URL but had no validation

Solution:
- Add production check: throw if DATABASE_URL is missing in NODE_ENV=production
- Dev/CI fallback to localhost URL for non-production prisma CLI operations
- CI workflows pass DATABASE_URL via env vars for build and validate steps
- Dockerfile builder stage has ENV for npm run build; runner stage does not (correct for production)

Changes:
- prisma.config.ts: production check + documented fallback URL
- src/lib/prisma.ts: production check for runtime
- vitest.setup.ts: dummy DATABASE_URL for test environment
- .github/workflows/ci.yaml: DATABASE_URL env var for validate job
- .github/workflows/image.yaml: pass DATABASE_URL to prisma validate docker run
- Dockerfile: ENV in builder stage only (for npm run build)

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

PR Review: fix(ci): use --no-engine for prisma validate in docker run

Summary

This PR fixes an issue where Prisma CLI validate throws errors during Docker image builds because NODE_ENV=production triggers a strict DATABASE_URL check before the build step can initialize the Prisma client. The solution makes the DATABASE_URL check conditional on production mode and provides a localhost fallback for build/CI scenarios.

Change-by-Change Findings

1. .github/workflows/image.yaml (+3/-1)

• Added clarifying comments explaining that DATABASE_URL is passed at runtime to allow prisma.config.ts to load.
• Existing docker run commands with --env DATABASE_URL remain unchanged.
• Finding: The comments are accurate and help future maintainers understand why runtime env passing is necessary. The comment about "builder stage ENV" refers to the Dockerfile change introduced in this PR.

2. Dockerfile (+4/-0)

• Adds ENV DATABASE_URL=postgresql://localhost:5432/dispatch to the builder stage before npm run build.
• Clear multi-line comments explain the scope: needed at build time for Next.js static generation, NOT inherited by the runner stage.
• Finding: Correct multi-stage Docker pattern. The builder stage needs DATABASE_URL to pass the conditional check (NODE_ENV=production + DATABASE_URL), while the runner stage will receive DATABASE_URL at container runtime from orchestrators or the workflow's --env flag.

3. prisma.config.ts (+5/-2)

• Changed the DATABASE_URL validation check from unconditional to process.env.NODE_ENV === "production" && !databaseUrl.
• Added a localhost fallback for the datasource URL: databaseUrl ?? "postgresql://localhost:5432/dispatch".
• Finding: This allows prisma generate and prisma validate (without engine) to run without a real database in dev/CI. Production still enforces DATABASE_URL via the conditional check.

4. src/lib/prisma.ts (+2/-4)

• Removed the module-level databaseUrl variable and moved the check inline.
• Changed validation from unconditional to process.env.NODE_ENV === "production" && !process.env.DATABASE_URL.
• Finding: The conditional pattern matches the change in prisma.config.ts. Using non-null assertion (!) after the production-mode check is safe since the check guards against undefined.

Standards Compliance

• ✅ Error handling: Both files use throw new Error("...") with meaningful messages per AGENTS.md convention.
• ✅ No commit of secrets: No hardcoded secrets in the diff; localhost fallback uses generic placeholder.
• ✅ Docker conventions: Multi-stage build pattern maintained; comments explain stage-specific ENV behavior.
• ✅ Consistent patterns: All changes follow the existing codebase style for environment variable handling.

Linked Issue Fit

• No linked issue found in PR body. The PR body (refs #249) describes the problem clearly: Prisma CLI validate throws in production mode when DATABASE_URL is unset, even with --no-engine.
• The fix solves the root cause without requiring --no-engine by making the DATABASE_URL check conditional on production mode.

Evidence Provider Findings

• No evidence providers configured.

Tool Harness Findings

• No tool output available.

Unknowns / Needs Verification

1. PR title vs. body mismatch: The PR title mentions "use --no-engine for prisma validate" but the workflow file changes do not include --no-engine flag. However, the PR body explains the underlying issue correctly, and the solution (conditional DATABASE_URL check) is more robust than relying on a flag. No action required.
2. Runtime DATABASE_URL risk: The Dockerfile adds a localhost default in the builder stage. If the runner stage accidentally inherits this ENV (e.g., via incorrect multi-stage COPY), production code would silently use localhost instead of crashing. Given src/lib/prisma.ts still validates DATABASE_URL in production mode, this is mitigated, but worth monitoring.

Recommendation

Approve. The PR correctly addresses the reported issue. The conditional DATABASE_URL check allows Docker builds to succeed while maintaining production safety. Changes are internally consistent, follow repository conventions, and introduce no breaking changes.