mirror of
https://github.com/BerriAI/litellm.git
synced 2026-08-28 05:25:59 +00:00
deab3676e8
The standalone migration entrypoint re-runs `prisma generate` after the migration completes. That refresh writes into the installed prisma package in site-packages, which an arbitrary non-root uid cannot do, and which no uid can do under a read-only root filesystem. Both are supported configurations of the migrations Job: helm/litellm-helm/tests/migrations-job_tests.yaml asserts runAsNonRoot, runAsUser and readOnlyRootFilesystem all render. The write has always failed there, but the failure used to be swallowed. Making migration failures fatal turned it into a hard exit 1, so a Job that applied every migration correctly now reports Failed and blocks the rollout it was supposed to gate. The refresh is redundant in the shipped images: every Dockerfile generates the client at build time from the same baked schema, copies it into the runtime stage, and asserts it resolves there. It stays load-bearing only for a source checkout, where CircleCI runs the entrypoint under `set +e` and ignores the exit code anyway. So the call stays and only its exit code stops propagating; migration failures are still fatal. image-scan never ran on the change that introduced this, because its path filter did not list the entrypoint it exercises. Add prisma_migration.py and entrypoint.sh so the non-root offline migration test gates them from now on. |
||
|---|---|---|
| .. | ||
| actions | ||
| codeql | ||
| ISSUE_TEMPLATE | ||
| observatory | ||
| screenshots | ||
| scripts | ||
| workflows | ||
| ci-coverage-allowlist.yml | ||
| CODEOWNERS | ||
| dependabot.yaml | ||
| deploy-on-aws.png | ||
| deploy-on-gcp.png | ||
| deploy-to-aws.png | ||
| FUNDING.yml | ||
| pull_request_template.md | ||
| template.yaml | ||
