Spike: CI Postgres version mismatch (16 vs prod 17.4) and pipeline audit #138

New issue

Closed

opened 2026-06-07 01:31:36 +00:00 by ldraney · 0 comments

ldraney commented

2026-06-07 01:31:36 +00:00

Owner

Type

Spike

Lineage

Emerged from paldocs #15 CI/CD infrastructure work. While aligning paldocs CI to the landscaping-assistant pattern, discovered landscaping-assistant itself has a CI-vs-prod Postgres version mismatch and that basketball-api infrastructure keeps getting falsely correlated with landscaping-assistant.

Repo

ldraney/landscaping-assistant (primary), ldraney/pal-e-platform (terraform investigation)

Question

Why does the landscaping-assistant CI test against Postgres 16 when production runs Postgres 17.4, and where in the infrastructure does the false basketball-api correlation originate?

CI services block uses postgres:16 -- when was this set, and was it ever correct?
Production uses CNPG pal-e-postgres at ghcr.io/cloudnative-pg/postgresql:17.4-1 -- is there any Postgres 16 in landscaping-assistant's actual dependency chain?
pal-e-platform/terraform/modules/database/main.tf manages both the CNPG operator AND basketball-api admin_app user provisioning in the same file -- should these be decoupled?
Are there any other places where basketball-api config leaks into landscaping-assistant's sphere (secrets, env vars, network policies)?
Does the landscaping-assistant pipeline have any other drift from the latest CI pattern (paldocs PR #21)?

Deliverables

docs/ci-postgres-audit.md documenting findings: version history, coupling sources, recommended changes
Follow-up ticket(s) for: CI Postgres version bump, any pipeline drift fixes, terraform decoupling recommendation

Time-box

1 session. If the terraform investigation goes deeper than expected, document findings and escalate.

paldocs ldraney/paldocs#15 -- the CI/CD pattern being standardized
pal-e-platform/terraform/modules/database/main.tf -- the coupling source
pal-e-platform/terraform/modules/ci/main.tf -- CNPG cluster at Postgres 17.4

### Type Spike ### Lineage Emerged from paldocs #15 CI/CD infrastructure work. While aligning paldocs CI to the landscaping-assistant pattern, discovered landscaping-assistant itself has a CI-vs-prod Postgres version mismatch and that basketball-api infrastructure keeps getting falsely correlated with landscaping-assistant. ### Repo `ldraney/landscaping-assistant` (primary), `ldraney/pal-e-platform` (terraform investigation) ### Question Why does the landscaping-assistant CI test against Postgres 16 when production runs Postgres 17.4, and where in the infrastructure does the false basketball-api correlation originate? - CI services block uses `postgres:16` -- when was this set, and was it ever correct? - Production uses CNPG `pal-e-postgres` at `ghcr.io/cloudnative-pg/postgresql:17.4-1` -- is there any Postgres 16 in landscaping-assistant's actual dependency chain? - `pal-e-platform/terraform/modules/database/main.tf` manages both the CNPG operator AND basketball-api admin_app user provisioning in the same file -- should these be decoupled? - Are there any other places where basketball-api config leaks into landscaping-assistant's sphere (secrets, env vars, network policies)? - Does the landscaping-assistant pipeline have any other drift from the latest CI pattern (paldocs PR #21)? ### Deliverables - [ ] `docs/ci-postgres-audit.md` documenting findings: version history, coupling sources, recommended changes - [ ] Follow-up ticket(s) for: CI Postgres version bump, any pipeline drift fixes, terraform decoupling recommendation ### Time-box 1 session. If the terraform investigation goes deeper than expected, document findings and escalate. ### Related - paldocs `ldraney/paldocs#15` -- the CI/CD pattern being standardized - `pal-e-platform/terraform/modules/database/main.tf` -- the coupling source - `pal-e-platform/terraform/modules/ci/main.tf` -- CNPG cluster at Postgres 17.4