Skip to content

feat(container): update image ghcr.io/berriai/litellm-database ( v1.96.0 ➔ v1.97.0 ) - #276

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/ghcr.io-berriai-litellm-database-1.x
Open

feat(container): update image ghcr.io/berriai/litellm-database ( v1.96.0 ➔ v1.97.0 )#276
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/ghcr.io-berriai-litellm-database-1.x

Conversation

@renovate

@renovate renovate Bot commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Update Change
ghcr.io/berriai/litellm-database (source) minor v1.96.0v1.97.0

Release Notes

BerriAI/litellm (ghcr.io/berriai/litellm-database)

v1.97.0

Compare Source

Verify Docker Image Signature

All LiteLLM Docker images are signed with cosign. Every release is signed with the same key introduced in commit 0112e53.

Verify using the pinned commit hash (recommended):

A commit hash is cryptographically immutable, so this is the strongest way to ensure you are using the original signing key:

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.97.0

Verify using the release tag (convenience):

Tags are protected in this repository and resolve to the same key. This option is easier to read but relies on tag protection rules:

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/v1.97.0/cosign.pub \
  ghcr.io/berriai/litellm:v1.97.0

Expected output:

The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

What's Changed

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "every weekend"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@kylin-hnimn-art

Copy link
Copy Markdown

Now posting the review.

Review: ghcr.io/berriai/litellm-database v1.96.0 → v1.96.2

  1. What changed? Patch bump (v1.96.0v1.96.2) of ghcr.io/berriai/litellm-database in kubernetes/apps/ai/litellm/app/deployment.yaml (both the db-migrate initContainer and the litellm container), plus the paired grafanadashboard.yaml dashboard-source URL tag (Renovate-linked via the # renovate: datasource=docker depName=... comment).

  2. Breaking change / deprecation flagged upstream? v1.96.2's release notes (gh api repos/BerriAI/litellm/releases/tags/v1.96.2) show it's a backport-only release on top of v1.96.0: it cherry-picks upstream PR #36011, fix(proxy)!: apply request-parameter checks consistently across body, path and form inputs — a security fix (closes an SSRF-adjacent gap where path/form-supplied destinations and connection tests could bypass request-parameter/credential checks that only covered request bodies before). The ! marks it conventional-commits-breaking, but three admin opt-outs are preserved for anyone relying on the old permissive behavior. (v1.96.1 itself was burned by a PyPI storage failure and re-cut as v1.96.2 with identical content — no separate git tag exists for .1.)

  3. Does this repo touch the affected behavior? No. configmap.yaml sets no model_list (models live in the DB per store_model_in_db: true) and doesn't use any of the three preserved opt-outs (path-based deployment overrides, bracket-notation form metadata, or per-model connection-test credential sharing). The stricter default behavior is a net positive here, not a regression risk.

  4. Manifest/dashboard-URL agreement? Both deployment.yaml image refs and the grafanadashboard.yaml URL consistently point to v1.96.2 — no drift, no leftover pins. Independently verified raw.githubusercontent.com/BerriAI/litellm/v1.96.2/.../grafana_dashboard.json returns HTTP 200, and gh api repos/BerriAI/litellm/tags confirms a real v1.96.2 git tag exists (this pairing has drifted before on past litellm PRs — not the case here).

  5. Verdict: merge — clean patch bump carrying an upstream security fix, no behavior in this repo depends on what changed, and the dashboard-URL/image-tag pairing is verified in sync.


Kylin · task t_31683688

@renovate
renovate Bot force-pushed the renovate/ghcr.io-berriai-litellm-database-1.x branch from 2d87b44 to 850d84e Compare August 16, 2026 01:02
@renovate renovate Bot changed the title fix(container): update image ghcr.io/berriai/litellm-database ( v1.96.0 ➔ v1.96.2 ) feat(container): update image ghcr.io/berriai/litellm-database ( v1.96.0 ➔ v1.97.0 ) Aug 16, 2026
@kylin-hnimn-art

Copy link
Copy Markdown

Now I have everything needed for the review.


Review: PR #276ghcr.io/berriai/litellm-database v1.96.0 → v1.97.0

Note on the task title vs. actual PR content: the title given to me (v1.96.0 ➔ v1.96.2, patch bump) is stale — Renovate has since rebased this same PR/branch to v1.96.0 ➔ v1.97.0 (minor). The commit and PR body on GitHub confirm v1.97.0 is what's actually being merged, so the review below is against that.

  1. What changed? ghcr.io/berriai/litellm-database v1.96.0v1.97.0minor bump. Touches deployment.yaml (both db-migrate initContainer and litellm container image) and grafanadashboard.yaml's dashboard URL tag.

  2. Breaking changes/deprecations? No. Best-available changelog for this range (v1.97.0-rc.1's "What's Changed") is all fix/feat/test/ci entries — no !: breaking-change markers. Nothing touches Prisma/migrations, DISABLE_SCHEMA_UPDATE, auth env vars, or the /health/readiness and /health/liveliness probe paths this repo relies on.

  3. Does this repo call the changed behavior? Checked deployment.yaml and configmap.yaml — nothing in the changelog intersects store_model_in_db, the db-migrate prisma flow, or probe endpoints used here.

  4. Manifest/lockfile agreement? deployment.yaml's two image refs and grafanadashboard.yaml's Renovate-tracked URL all consistently bump to v1.97.0 — no drift between them. However, independently verified against upstream (per [[litellm_dashboard_url_tag_drift]] memory — this bug has now recurred a third time): ghcr.io/berriai/litellm-database:v1.97.0 pulls fine (ghcr manifest 200), but the git tag v1.97.0 does not exist yet on BerriAI/litellm — only v1.97.0-dev.1/2 and v1.97.0-rc.1 pre-release tags, with v1.98.0-dev.2 already published ahead of it. Confirmed directly: raw.githubusercontent.com/BerriAI/litellm/v1.97.0/cookbook/.../grafana_dashboard.json404. Merging as-is will break grafana-operator's reconcile of the GrafanaDashboard CR.

  5. Verdict: hold — the container image bump itself is safe (no breaking changes, nothing in this repo touches the affected code paths), but the grafanadashboard.yaml URL bump to v1.97.0 404s because BerriAI hasn't cut that git tag yet. Merge only after either (a) reverting/pinning the dashboard URL to v1.96.0 (last known-good tag) while still bumping the image, or (b) waiting for Renovate to catch up once BerriAI actually cuts the v1.97.0 git tag.


Kylin · task t_7207282f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants