Skip to content

chore(e2e): move the compat-matrix populator from a GCE VM to a Render cron job - #42608

Merged
mateo-berri merged 9 commits into
mainfrom
litellm_compat_matrix_render_cron
Sep 23, 2026
Merged

mateo-berri merged 9 commits into
mainfrom
litellm_compat_matrix_render_cron

Conversation

@devin-ai-integration

@devin-ai-integration devin-ai-integration Bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

TLDR

Problem this solves:

  • The daily compat-matrix populator runs on a hand-built GCE VM
  • Its systemd units, tool versions, and secrets exist only on that box
  • Nobody can rebuild it from the repo if the VM dies
  • The stale-PR sweep missed docs PR [Feature]: Add support for Nvidia AI Foundation endpoints  #1266, so it sat open two weeks
  • run_daily.sh copies five helpers by name into the worktree, and main's helpers now import fixture_mode, so a fresh checkout of the script fails at conftest load (the VM ran a stale snapshot and never hit it)

How it solves it:

  • A Dockerfile plus a Render cron job replace the VM and systemd
  • gh, uv, and the Claude Code CLI are pinned and checksum-verified
  • The run installs the release's PyPI wheel instead of building the tag
  • The publish token and Vertex key arrive as Render secret files
  • The sweep pages past the newest 100 open docs PRs and only closes PRs the publishing account opened from the docs repo's own branches, so a contributor's PR under the same prefix is never touched
  • The shim copies the whole tests/e2e tree and confines pytest's conftest loading to claude_code/
  • A CI job builds the image on every PR that touches it

User Flow

Before: the populator lives on a GCE VM, so checking or rerunning it takes IAP SSH to that box

  1. They open https://console.cloud.google.com/compute/instances?project=vertex-check-481318 and find litellm-compatibility-matrix-populator
  2. They run gcloud compute ssh litellm-compatibility-matrix-populator --zone us-central1-f --project vertex-check-481318 --tunnel-through-iap and read the last run with journalctl -u litellm-compat-matrix
  3. To rerun they run sudo systemctl start litellm-compat-matrix on the VM and wait about 12 minutes
  4. The run pushes compat-matrix/v1.101.0-2.1.228-2026-09-22 and opens chore(compat-matrix): refresh for v1.101.0 + claude-code 2.1.228 litellm-docs#1622 with squash auto-merge on
  5. The sweep prints nothing, and chore(compat-matrix): refresh for v1.100.0 + claude-code 2.1.228 litellm-docs#1266 from 2026-09-08 stays open
  6. Rotating the publish token means editing /etc/litellm-compat-matrix-github-token on the VM over SSH

After: the populator is the Render cron job litellm-compat-matrix, worked from the Render dashboard or its API

  1. They open https://dashboard.render.com/cron/crn-dapgapoae00c73d16130 and see the schedule 0 6 * * * and the last run's status
  2. They read the last run on the Logs tab, or with GET https://api.render.com/v1/logs?ownerId=&resource=crn-dapgapoae00c73d16130
  3. To rerun they click Trigger Run, or POST https://api.render.com/v1/cron-jobs/crn-dapgapoae00c73d16130/runs, which returns 200 with "status": "pending"
  4. The run pushes compat-matrix/v1.102.0-2.1.228-2026-09-23 and opens chore(compat-matrix): refresh for v1.102.0 + claude-code 2.1.228 litellm-docs#1643 with squash auto-merge on
  5. The sweep closes chore(compat-matrix): refresh for v1.100.0 + claude-code 2.1.228 litellm-docs#1266 as superseded
  6. Rotating the publish token means replacing the github-token secret file on the service's Environment tab
  7. After a merge that touches tests/e2e/** they click Manual Deploy (or POST https://api.render.com/v1/services/crn-dapgapoae00c73d16130/deploys) before the next run

Relevant issues

None

Affected release

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have added meaningful tests (the Compat Matrix Image job builds the image and runs the pinned binaries on every PR that touches it; nothing here is unit-testable Python)
  • The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more (no Python test files change; the image built locally with the same docker build the job runs)
  • My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
  • My PR's scope is as isolated as possible; it only solves 1 specific problem
  • I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Before (95d4613)

The populator is the VM's systemd timer, and its 06:00 UTC run today left docs PR #1266 open

  1. gcloud compute ssh litellm-compatibility-matrix-populator --zone us-central1-f --project vertex-check-481318 --tunnel-through-iap --quiet --command 'systemctl list-timers litellm-compat-matrix.timer'

    NEXT                        LEFT    LAST                        PASSED  UNIT                        ACTIVATES
    Wed 2026-09-23 06:07:12 UTC 7h left Tue 2026-09-22 06:00:29 UTC 17h ago litellm-compat-matrix.timer litellm-compat-matrix.service
    
  2. ... --command 'systemctl show litellm-compat-matrix -p Result,ExecMainStartTimestamp,ExecMainExitTimestamp'

    Result=success
    ExecMainStartTimestamp=Tue 2026-09-22 06:00:29 UTC
    ExecMainExitTimestamp=Tue 2026-09-22 06:12:00 UTC
    
  3. ... --command 'journalctl -u litellm-compat-matrix --since "2026-09-22 06:00" -o short-iso | grep -E "==>|pull/"'

    2026-09-22T06:00:47+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> starting proxy on 127.0.0.1:4100
    2026-09-22T06:01:03+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> running pytest
    2026-09-22T06:11:30+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> pytest exit code: 0 (failures become 'fail' cells, not script errors)
    2026-09-22T06:11:30+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> building /tmp/litellm-compat-matrix.J1N64h/compatibility-matrix.json
    2026-09-22T06:11:30+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> cloning BerriAI/litellm-docs@main
    2026-09-22T06:11:53+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> checking for green->red regressions vs the published matrix
    2026-09-22T06:11:55+0000 litellm-compatibility-matrix-populator run_daily.sh[3779034]: remote:      https://github.com/BerriAI/litellm-docs/pull/new/compat-matrix/v1.101.0-2.1.228-2026-09-22
    2026-09-22T06:11:55+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> opening PR from compat-matrix/v1.101.0-2.1.228-2026-09-22 -> BerriAI/litellm-docs:main (as mateo-berri)
    2026-09-22T06:11:57+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: https://github.com/BerriAI/litellm-docs/pull/1622
    2026-09-22T06:11:57+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> enabling squash auto-merge on compat-matrix/v1.101.0-2.1.228-2026-09-22
    2026-09-22T06:11:58+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> sweeping stale compat-matrix PRs (keeping compat-matrix/v1.101.0-2.1.228-2026-09-22)
    2026-09-22T06:11:58+0000 litellm-compatibility-matrix-populator run_daily.sh[3768215]: ==> done
    

    The sweep closed nothing: with --limit 100 the list never reaches a two-week-old PR in a repo with about 360 open PRs

  4. gh pr list --repo BerriAI/litellm-docs --state open --limit 1000 --json number,headRefName,createdAt --jq '.[] | select(.headRefName | startswith("compat-matrix/")) | "\(.number)\t\(.headRefName)\t\(.createdAt)"'

    1266	compat-matrix/v1.100.0-2.1.228-2026-09-08	2026-09-08T06:42:55Z
    

After, first pass (d244364)

The populator is the Render cron job litellm-compat-matrix (crn-dapgapoae00c73d16130), deployed from this PR's tip and triggered by hand instead of waiting for 06:00 UTC. RENDER_API_KEY is a Render personal API key; the same calls work from the Render dashboard's Manual Run and Logs buttons

  1. Deploy the tip and wait for it to go live

    curl -s -X POST -H "Authorization: Bearer $RENDER_API_KEY" -H "Content-Type: application/json" https://api.render.com/v1/services/crn-dapgapoae00c73d16130/deploys -d '{"clearCache":"do_not_clear"}', then curl -s -H "Authorization: Bearer $RENDER_API_KEY" https://api.render.com/v1/services/crn-dapgapoae00c73d16130/deploys/dep-dapho2ijnfac73bpfj70 | jq '{id, commit: .commit.id, status, finishedAt}'

    {"id": "dep-dapho2ijnfac73bpfj70", "commit": "d24436407bc458f11b80cd8cd53c6582f1c38758", "status": "live", "finishedAt": "2026-09-23T00:23:59.753218Z"}
    
  2. Trigger a run

    curl -s -X POST -H "Authorization: Bearer $RENDER_API_KEY" https://api.render.com/v1/cron-jobs/crn-dapgapoae00c73d16130/runs | jq '{id, status}'

    {"id": "crn-dapgapoae00c73d16130-1790123071", "status": "pending"}
    
  3. Read the run's step lines (same ==> markers as the VM journal above)

    curl -s -H "Authorization: Bearer $RENDER_API_KEY" "https://api.render.com/v1/logs?ownerId=tea-codhik0l5elc73foatl0&resource=crn-dapgapoae00c73d16130&startTime=2026-09-23T00:24:30Z&direction=forward&limit=100" | jq -r '.logs[] | "\(.timestamp[11:19]) \(.message)"' | grep -E '==>|pull/|passed' (paged on nextStartTime until the run ends)

    00:24:31 ==> Cron job run started
    00:24:36 ==> publish token source: /etc/secrets/github-token
    00:25:09 ==> resolved litellm: v1.102.0
    00:25:09 ==> local claude code: 2.1.228
    00:25:09 ==> first run: cloning litellm into /home/populator/litellm-cron-worktree
    00:25:28 ==> updating worktree to v1.102.0
    00:25:40 ==> shimming tests/e2e/ from /opt/litellm (always-overwrite)
    00:25:40 ==> downloading uv 0.10.9 for the worktree
    00:25:41 ==> uv sync --frozen --group proxy-dev --extra proxy --no-install-project --python 3.12 (uv 0.10.9)
    00:25:50 ==> installing the published litellm==1.102.0 wheel from PyPI
    00:25:52 ==> starting proxy on 127.0.0.1:4100
    00:26:08 ==> running pytest
    00:40:50 =========== 80 passed, 17 skipped, 76 warnings in 878.82s (0:14:38) ============
    00:40:50 ==> pytest exit code: 0 (failures become 'fail' cells, not script errors)
    00:40:50 ==> building /tmp/litellm-compat-matrix.stQSRx/compatibility-matrix.json
    00:40:50 ==> cloning BerriAI/litellm-docs@main
    00:41:09 ==> checking for green->red regressions vs the published matrix
    00:41:11 ==> opening PR from compat-matrix/v1.102.0-2.1.228-2026-09-23 -> BerriAI/litellm-docs:main (as mateo-berri)
    00:41:13 https://github.com/BerriAI/litellm-docs/pull/1643
    00:41:13 ==> enabling squash auto-merge on compat-matrix/v1.102.0-2.1.228-2026-09-23
    00:41:16 ==> sweeping stale compat-matrix PRs (keeping compat-matrix/v1.102.0-2.1.228-2026-09-23)
    00:41:21 ==> closed stale compat-matrix PR #1266 (compat-matrix/v1.100.0-2.1.228-2026-09-08)
    00:41:21 ==> done
    00:41:25 ==> Cron job run finished successfully
    

    The 80 passed and 17 skipped match the VM's last run on the same suite; the run resolved v1.102.0, which shipped after the VM's 06:00 run picked v1.101.0

  4. Confirm how the run ended

    curl -s -H "Authorization: Bearer $RENDER_API_KEY" "https://api.render.com/v1/services/crn-dapgapoae00c73d16130/events?limit=1" | jq '.[0].event'

    {"type": "cron_job_run_ended", "details": {"cronJobRunId": "crn-dapgapoae00c73d16130-1790123071", "status": "successful"}}
    
  5. The docs PR it opened, and the stale one it closed

    gh pr view 1643 --repo BerriAI/litellm-docs --json number,state,headRefName,autoMergeRequest,author --jq '{number, state, headRefName, autoMerge: (.autoMergeRequest != null), author: .author.login}'

    {"author":"mateo-berri","autoMerge":true,"headRefName":"compat-matrix/v1.102.0-2.1.228-2026-09-23","number":1643,"state":"OPEN"}
    

    gh pr view 1266 --repo BerriAI/litellm-docs --json number,state,closedAt,headRefName

    {"closedAt":"2026-09-23T00:41:20Z","headRefName":"compat-matrix/v1.100.0-2.1.228-2026-09-08","number":1266,"state":"CLOSED"}
    

    gh pr list --repo BerriAI/litellm-docs --state open --limit 1000 --json number,headRefName --jq '[.[] | select(.headRefName | startswith("compat-matrix/"))]'

    [{"headRefName":"compat-matrix/v1.102.0-2.1.228-2026-09-23","number":1643}]
    

After (1f93010)

Same job, redeployed at the tip after the sweep was scoped to the publishing account's own PRs, and run again the same way

  1. curl -s -H "Authorization: Bearer $RENDER_API_KEY" https://api.render.com/v1/services/crn-dapgapoae00c73d16130/deploys/dep-dapillp42hec73b2lqng | jq '{id, commit: .commit.id, status}'

    {"id": "dep-dapillp42hec73b2lqng", "commit": "1f930105cbb54636ab5dfbb32771682b0388a811", "status": "live"}
    
  2. curl -s -X POST -H "Authorization: Bearer $RENDER_API_KEY" https://api.render.com/v1/cron-jobs/crn-dapgapoae00c73d16130/runs | jq '{id, status}'

    {"id": "crn-dapgapoae00c73d16130-1790126848", "status": "pending"}
    
  3. Step lines (same log call as above, startTime=2026-09-23T01:27:28Z)

    01:27:28 ==> Cron job run started
    01:27:34 ==> publish token source: /etc/secrets/github-token
    01:27:34 ==> publishing as mateo-berri
    01:27:36 ==> resolved litellm: v1.102.0
    01:27:36 ==> local claude code: 2.1.228
    01:27:36 ==> first run: cloning litellm into /home/populator/litellm-cron-worktree
    01:27:56 ==> updating worktree to v1.102.0
    01:28:01 ==> shimming tests/e2e/ from /opt/litellm (always-overwrite)
    01:28:02 ==> downloading uv 0.10.9 for the worktree
    01:28:03 ==> uv sync --frozen --group proxy-dev --extra proxy --no-install-project --python 3.12 (uv 0.10.9)
    01:28:10 ==> installing the published litellm==1.102.0 wheel from PyPI
    01:28:11 ==> starting proxy on 127.0.0.1:4100
    01:28:25 ==> running pytest
    01:38:55 =========== 80 passed, 17 skipped, 76 warnings in 627.25s (0:10:27) ============
    01:38:55 ==> pytest exit code: 0 (failures become 'fail' cells, not script errors)
    01:38:55 ==> building /tmp/litellm-compat-matrix.wlwiQ3/compatibility-matrix.json
    01:38:55 ==> cloning BerriAI/litellm-docs@main
    01:39:14 ==> checking for green->red regressions vs the published matrix
    01:39:16 ==> opening PR from compat-matrix/v1.102.0-2.1.228-2026-09-23 -> BerriAI/litellm-docs:main (as mateo-berri)
    01:39:19 https://github.com/BerriAI/litellm-docs/pull/1645
    01:39:19 ==> enabling squash auto-merge on compat-matrix/v1.102.0-2.1.228-2026-09-23
    01:39:22 ==> sweeping stale compat-matrix PRs (keeping compat-matrix/v1.102.0-2.1.228-2026-09-23)
    01:39:24 ==> done
    01:39:28 ==> Cron job run finished successfully
    

    The sweep found nothing to close: chore(compat-matrix): refresh for v1.102.0 + claude-code 2.1.228 litellm-docs#1643 from the run above had already auto-merged at 00:46Z, so this run's PR is the same-day refresh (generated_at is the only cell that moved), and it auto-merged too

    gh pr view 1645 --repo BerriAI/litellm-docs --json number,state,mergedAt,author --jq '{number, state, mergedAt, author: .author.login}'

    {"author":"mateo-berri","mergedAt":"2026-09-23T01:44:20Z","number":1645,"state":"MERGED"}
    
  4. The VM is gone and the project stays

    gcloud compute ssh litellm-compatibility-matrix-populator --zone us-central1-f --project vertex-check-481318 --tunnel-through-iap --quiet --command 'sudo systemctl disable --now litellm-compat-matrix.timer && systemctl list-timers litellm-compat-matrix.timer --all'

    Removed "/etc/systemd/system/timers.target.wants/litellm-compat-matrix.timer".
    NEXT LEFT LAST PASSED UNIT ACTIVATES
    
    0 timers listed.
    

    gcloud compute instances delete litellm-compatibility-matrix-populator --zone us-central1-f --project vertex-check-481318 --quiet && gcloud compute instances list --project vertex-check-481318 && gcloud projects describe vertex-check-481318 --format='value(projectId,lifecycleState)'

    Deleted [https://www.googleapis.com/compute/v1/projects/vertex-check-481318/zones/us-central1-f/instances/litellm-compatibility-matrix-populator].
    Listed 0 items.
    vertex-check-481318	ACTIVE
    

Type

🚄 Infrastructure

Caveats (if any)

Medium

  • Pushes never redeploy the cron job
    • Render's GitHub app is not installed on the BerriAI org (an org admin step), so autoDeploy: yes never fires
    • After a merge that touches tests/e2e/**, deploy by hand (README shows the API call); the next scheduled run otherwise uses the old image
  • The run installs the release's PyPI wheel, not the tag's source
    • The tag builds a Rust extension through maturin, and the image carries no C or Rust toolchain
    • The wheel is what users install, so the matrix measures the shipped build
    • A release whose wheel is missing on PyPI fails at the install step instead of building (never happened so far; PyPI has led the GitHub release every time)

Low

  • Tool pins (gh 2.101.0, uv 0.10.9, Claude Code 2.1.228) bump through a PR with the new checksum
  • The CI job only builds the image and runs --version on the pinned binaries; it never runs the suite (real providers, about 12 minutes, real cost)
  • Every run starts cold (the container disk does not persist), so the first clone is blobless (--filter=blob:none) to keep it short
  • The sweep lists up to 1000 open docs PRs authored by the publishing account (resolved from the token with gh api user); the docs repo carries about 360 open PRs today
  • The close comment on a swept PR lost its trailing period (house style)
  • pytest runs with --confcutdir=tests/e2e/claude_code, so the tree's top-level conftest.py never loads (the VM never loaded it either); the covers marker it registers stays unregistered, so collection prints one PytestUnknownMarkWarning per test, as before
  • The GCE VM's timer is disabled and the VM is deleted (proof step 4 above), so only the Render job fires from 2026-09-23 on; the project itself stays
  • The misc / Run tests job was red at the tip on tests/test_litellm/test_utils.py::test_wrapper_async_does_not_fire_failure_hook_for_post_success_error, which fix(utils): isolate callback errors in async_post_call_success_deployment_hook #42535 broke on main at 00:59Z (main's own Unit Tests runs failed on that test from https://github.com/BerriAI/litellm/actions/runs/35804440599 on); this PR changes only a shell script, a Dockerfile, a workflow, and docs. test(utils): raise the post-success hook error from a guardrail in the failure-hook regression #42646 fixed the test on main at 02:11Z, and the PR reopened at the same tip is green on it: https://github.com/BerriAI/litellm/actions/runs/35810558292 (6563 passed, 25 skipped, on the merge into 5fa1257)

/live-pr-risk

Verdict: no dependent path outside the cron job itself; the one dependent path (the container's daily run) was driven live on both sides

  • Breaking: none found

  • Backward incompatible: none for any proxy, SDK, dashboard, or config consumer; the diff touches no file that loads into a proxy process

    • The operator contract changed on purpose: the populator is now a Render cron job, and the systemd unit and timer are gone (the whole point of the PR)
  • Regression risk: a release whose PyPI wheel lags the GitHub tag fails at the install step (every release so far had the wheel first); a Claude Code CLI bump is a PR with a checksum instead of the VM's auto-updater

  • Dependency graph (repo-wide sweep for run_daily.sh, cron_vm/, litellm-compat-matrix.*, CREDENTIALS_DIRECTORY, compatibility-matrix-populator)

    • Dockerfile CMD -> run_daily.sh: verified live (the Render run below)
    • run_daily.sh -> build_matrix.py, check_regressions.py (CLI output read back): verified live, same run
    • run_daily.sh sweep -> gh pr list --author <login> on the docs repo: the exact query was run live as the publishing account (open PRs: none left; closed: [Feature]: Allow setting names for keys  #1643 and [Feature]: Add new gpt-3.5-turbo-0125 [Week of Jan 28th]  #1622 match, a fork PR under the prefix does not)
    • tests/e2e/claude_code/passthrough/test_azure.py:12 and _builder_unit_tests/test_matrix_builder.py:2 name the env example and cron_vm/ in docstrings only: still accurate
    • .github/workflows/compat-matrix-image.yml -> Dockerfile: verified on this PR's checks
    • Nothing under litellm/, enterprise/, ui/, or litellm/proxy/client/ references any changed file, so no proxy A/B rig applies
  • Not verified: nothing skipped

  • 1f93010 passes /live-pr-risk

…r cron job

The daily Claude Code compatibility-matrix job ran as a systemd timer on
the litellm-compatibility-matrix-populator VM in the vertex-check GCP
project. Replace that with a Render Docker cron job built from a new
Dockerfile in tests/e2e/claude_code/cron_vm: pinned and checksummed
debian base, gh, uv, and Claude Code CLI, a non-root populator user, and
run_daily.sh as the entrypoint. run_daily.sh now clones a fresh blobless
checkout per run (Render cron disks are ephemeral), reads the publish PAT
from the github-token secret file under CREDENTIALS_DIRECTORY, and its
comments no longer describe systemd. The .service and .timer units are
gone; README.md and the env example describe the Render service, its
secret files, and the local docker build instead.
@devin-ai-integration

devin-ai-integration Bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor Author

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

  • Disable automatic comment, CI, and merge conflict monitoring

Render answers a bare 404 for the legacy pro_max plan name on a cron job
(4c-16g is the same 4 CPU / 16 GB size) and the manual trigger route is
/v1/cron-jobs, not /v1/cronjobs.
@greptile-apps

greptile-apps Bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerConfidence Score: 5/5

The PR appears safe to merge; both previous findings are resolved and no new changes or outstanding failures remain.

Summary

The PR replaces the hand-maintained GCE compatibility-matrix runner with a reproducible Render cron image.

  • Adds a non-root Docker image with pinned, checksum-verified CLI dependencies.
  • Updates the runner to install the released PyPI wheel, copy the complete current E2E tree, and isolate pytest conftest loading.
  • Moves credentials to Render secret files and documents deployment and operations.
  • Expands the stale-PR sweep while restricting it to same-repository PRs created by the publishing identity.
  • Adds a path-filtered CI workflow that builds the image and validates its pinned binaries.

Reviews (5) · Last reviewed commit: "fix(e2e): scope the compat-matrix sweep ..."

Comment thread tests/e2e/claude_code/cron_vm/Dockerfile
@codecov

codecov Bot commented Sep 22, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

… tag from source

The tag builds a Rust extension through maturin, which needs a C and Rust
toolchain the cron image does not carry, so the first Render run failed at
uv sync with "linker cc not found". Sync the locked dependencies with
--no-install-project, install the PyPI wheel (what users run) with
--no-build, and pass --no-sync to every uv run so uv never puts the source
build back.
The validation run wrote the matrix into the image checkout, which nobody
can read once the container exits. Save it under HOME and print it at the
end of the log instead.
…0 docs PRs

The docs repo has a few hundred open PRs, so a 100-item list never
reached the week-old compat-matrix PR and the sweep left it open on
every run.
Pushes never started a deploy during setup because Render only hears
about them through its GitHub app, which the org does not have, so the
README now carries the deploy command and the wait-for-live rule
The CI coverage gate requires every Dockerfile to be built by a job, and
building this one on each PR that touches it also catches a broken pin
or checksum before Render does
The five-file helper allowlist missed fixture_mode, which e2e_config now
imports, so the first Render run died at conftest load with
ModuleNotFoundError. Copy the image's whole tests/e2e tree instead and
keep pytest from loading the EKS-harness conftest with --confcutdir
@mateo-berri

Copy link
Copy Markdown
Contributor

@greptileai

@mateo-berri

Copy link
Copy Markdown
Contributor

bugbot run

Comment thread tests/e2e/claude_code/cron_vm/run_daily.sh Outdated

@cursor cursor Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

…wn PRs

The stale-PR sweep selected every open docs PR whose head branch starts
with compat-matrix/, so a contributor's fork PR under that name would
have been closed once a newer matrix PR existed. The sweep now resolves
the publishing login from the token and only closes same-repo PRs that
account opened
@mateo-berri

Copy link
Copy Markdown
Contributor

@greptileai

@mateo-berri

Copy link
Copy Markdown
Contributor

bugbot run

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 1f93010. Configure here.

@mateo-berri mateo-berri left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mateo-berri
mateo-berri merged commit 1bc7d34 into main Sep 23, 2026
295 of 298 checks passed
@mateo-berri
mateo-berri deleted the litellm_compat_matrix_render_cron branch September 23, 2026 02:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Allow setting names for keys

1 participant