fix: point shared-deployments to feature branch in deploy.yaml

[Matanya7491]

User description

Summary

Updates pipelines/deploy.yaml to reference the correct branch in shared-deployments while the Kubernetes values PR is pending merge.

Change:

- repository: deployments
  name: lsportsltd/shared-deployments
  ref: refs/heads/feature/add-bringits-validation-platform  # ← added

This tells Azure DevOps to use the feature/add-bringits-validation-platform branch of shared-deployments (where the values.yaml lives) instead of main.

After shared-deployments PR #9251 is merged, this ref should be removed so the pipeline uses main.

Related

• shared-deployments PR: https://github.com/lsportsltd/shared-deployments/pull/9251

Made with Cursor

---

Generated description

Below is a concise technical summary of the changes proposed in this PR:
Enable the backend’s bootstrap sequence to expose health/command-type metadata via MetaController, resolve runtime URLs, ensure the validation_platform database exists, and run Prisma migrations before NestFactory starts so the API is resilient on new deployments. Update the Docker/Next.js build pipeline, workspace metadata, and shared-deployments reference so the production container ships the compiled backend/web artifacts alongside the temporary feature branch values required for the bringits deployment flow.

Topic	Details
Backend bootstrap	Harden the backend bootstrap by mounting MetaController at the root to serve health and meta/command-types, by resolving link-db and Redis URLs from cloud secrets, and by ensuring the validation_platform database is created and migrated before NestJS listens so the service starts with predictable dependencies. Modified files (2) apps/backend/src/api/meta.controller.ts apps/backend/src/main.ts Latest Contributors(1) User Commit Date Matanya7491 fix: remove NODE_ENV=p... May 20, 2026
Build & deploy	Solidify the build-and-deploy flow by rebuilding the Docker multi-stage pipeline to target the standalone Next.js output, aligning the workspace identity in package-lock.json, and pointing pipelines/deploy.yaml at the shared-deployments feature branch so the production image contains the compiled backend/web assets plus the temporary values from bringits deployments. Modified files (4) Dockerfile apps/web/next.config.ts package-lock.json pipelines/deploy.yaml Latest Contributors(1) User Commit Date Matanya7491 fix: remove NODE_ENV=p... May 20, 2026

_{Review this PR on Baz | Customize your next review}

[baz-reviewer]

CONNECTION_MAP is snapshotted at PostgresCommand module load, so deriving CONN_LINK_API_URL/CONN_LINK_API_RO_URL after AppModule import can make connection: 'link_api'/'link_api_ro' miss and hit Unknown connection; can we move the env derivation before the AppModule require (or into a bootstrap module required first)?

_{Finding type: Breaking Changes | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/backend/src/main.ts around lines 1-66, fix the initialization order so
resolveDATABASE_URL() and resolveConnURLs() run before importing AppModule (and before
any modules/commands that snapshot process.env at module load). Refactor by moving the
env-derivation functions and their invocations above the AppModule import, or by
extracting them into a new tiny bootstrap file that main.ts imports first, then
importing AppModule afterwards. Ensure PostgresCommand (and any similar command that
builds CONNECTION_MAP at import time) observes CONN_LINK_API_URL and
CONN_LINK_API_RO_URL set during startup, so seeded postgres flows don’t fail with
“Unknown connection” when those env vars are derived internally.

[baz-reviewer]

DATABASE_URL without a /dbname path is valid for libpq but this ?? 'validation_platform' default can make ensureDatabase() connect/migrate the wrong DB; should we fail fast when the db name is missing, or parse/derive the actual database name from the URL?

_{Finding type: Logical Bugs | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/backend/src/main.ts around lines 73-107, inside ensureDatabase(), the code derives
dbName using dbUrl.match(/\/([^/?]+)(\?|$)/) and then defaults with match?.[1] ??
'validation_platform'. This silently chooses the wrong database when DATABASE_URL is a
valid Postgres URI without a /dbname path. Refactor ensureDatabase() to explicitly parse
the database name from DATABASE_URL (prefer URL/authority parsing), and if the dbname
component is missing/ambiguous, fail fast (throw or exit) with a clear error instead of
defaulting; then ensure adminUrl is built only from the correctly extracted dbName.

[baz-reviewer]

Since the Dockerfile now copies Next standalone into ./apps/web/.next/standalone, should we confirm the final image CMD actually starts node apps/web/.next/standalone/server.js (otherwise the copied server.js never runs), or split web into a dedicated container?

_{Finding type: Breaking Changes | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In Dockerfile around
lines 49-52 where you copy the Next.js standalone output (copying `.next/standalone` and
`.next/static` into `./apps/web/.next/...`), ensure the final runtime stage actually
starts the Next standalone server instead of only the backend. Update the final
stage’s CMD/ENTRYPOINT (outside this snippet) to run `node
apps/web/.next/standalone/server.js` (or ensure the correct working directory and paths)
and verify the web server listens on the configured PORT. If the project should not run
both services in one image, refactor by splitting into separate Dockerfiles/targets for
backend and web so each image starts its own entrypoint.

[baz-reviewer]

npm prune --omit=dev --workspace=apps/backend only targets that workspace, so later root-level npm ci plus copying /usr/src/app/node_modules can leave the final image with root-hoisted (incl dev) workspace deps. Can we also prune the root (or avoid copying the root tree) before building the runtime image?

_{Finding type: Logical Bugs | Severity: 🟢 Low}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In Dockerfile around
lines 30-31 (the `prod-deps` stage running `npm prune --omit=dev
--workspace=apps/backend`), fix the logic so the runtime image is truly
backend-only/prod-only. Currently the stage only prunes the backend workspace, but later
lines 38-39 copy `/usr/src/app/node_modules` into the production image, which came from
the root `npm ci` and can still include root/hoisted workspace links and dev
dependencies. Refactor the stages so either (a) you also prune the root project for
production deps (not just the backend workspace), and ensure workspace links like
`node_modules/web` are removed, or (b) you stop copying `/usr/src/app/node_modules` into
the final image and only copy `/usr/src/app/apps/backend/node_modules` plus the minimal
runtime files needed. After the change, verify the final image `node_modules` contains
only backend production dependencies (no web workspace link and no dev packages).

[baz-reviewer]

With output: 'standalone', server.js expects assets under .next/standalone/public and .next/standalone/.next/static, but this Dockerfile copies from apps/web/public and apps/web/.next/static; can we copy into the standalone tree paths so the server can actually find them?

_{Finding type: Logical Bugs | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In Dockerfile around
lines 37-39 in the production stage (the `COPY --from=build-web` commands for the
Next.js output), fix the path mismatch for Next.js `output: 'standalone'`. Right now
`public` and `.next/static` are copied to `apps/web/public` and `apps/web/.next/static`,
but the standalone `server.js` expects them under the standalone tree at
`apps/web/.next/standalone/public` and `apps/web/.next/standalone/.next/static`. Update
these COPY destinations so both `public` and static assets are placed inside
`apps/web/.next/standalone/` (and avoid copying them only to sibling directories), then
verify the standalone server can resolve them at runtime.

[baz-reviewer]

Commit db00321 addressed this comment by copying the built Next.js standalone tree (# .next/standalone) into the production image so the server can resolve its expected public and static assets paths, rather than only exposing the top-level public/.next/static directories.

[baz-reviewer]

Since prisma migrate deploy failures are only logged here, bootstrap() keeps running NestFactory.create()/listen() even if the schema didn’t apply, so Prisma-backed routes like GET /api/runs can serve against missing/stale tables. Can we exit or block readiness when migrations fail?

_{Finding type: Breaking Changes | Severity: 🔴 High}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
apps/backend/src/main.ts around lines 118-120 where you run `prisma migrate deploy`
(before calling `bootstrap()`), the migration error is being caught and only logged,
allowing `bootstrap()` / `NestFactory.create()` / `listen()` to proceed even if the
schema was not applied. Refactor so migration failure causes the process to stop (e.g.,
rethrow the error or call `process.exit(1)` after logging) so the service doesn’t
start and serve Prisma-backed routes with a missing/stale schema. Ensure this failure
prevents both app initialization and request handling when `prisma migrate deploy`
fails.