mirror of
https://github.com/BerriAI/litellm.git
synced 2026-08-28 05:25:59 +00:00
6a83a84f31
`prisma generate` runs `npm install prisma@<version>` whenever the
prisma-client-py binary cache directory has no CLI entrypoint, pulling ~85 MB
of query and schema engines over the network. Every workflow pointed
PRISMA_BINARY_CACHE_DIR at `${{ runner.temp }}/prisma-cache`, which GitHub
wipes and recreates per job, so that cache was empty on every job of every
run and the download was never avoidable.
The download is normally a few seconds and occasionally minutes. On one
proxy-db run it took 5m18s on a single shard against 3.8s on its eleven
siblings, which pushed the job past its 15 minute timeout and cancelled a
shard whose tests were at 99% and all passing.
Leave PRISMA_BINARY_CACHE_DIR unset so the binaries land in the
prisma-client-py default, which is already keyed by prisma and engine
version, and restore both that path and the @prisma/engines staging cache
through a shared composite action.
Job timeouts also counted setup against the test budget. `timeout-minutes`
now bounds the pytest step, with a separate allowance for checkout,
dependency install, and client generation, so slow setup shows up as a slow
job instead of a cancelled test run.
check_prisma_binary_cache.py guards all three invariants: no workflow
reintroduces the override, every job that generates the client restores the
cache, and the version the action greps out of uv.lock still resolves.
40 lines
1.7 KiB
YAML
40 lines
1.7 KiB
YAML
name: "Cache Prisma binaries"
|
|
description: >-
|
|
Cache the Prisma CLI and engine binaries that `prisma generate` downloads, so
|
|
only the first job on a given prisma-client-py version pays for the download.
|
|
|
|
prisma-client-py shells out to `npm install prisma@<version>` whenever its
|
|
binary cache directory has no CLI entrypoint, which pulls ~85 MB of query and
|
|
schema engines over the network. That normally takes a few seconds, but it is
|
|
unbounded: one shard of a proxy-db run took 5m18s on that single step versus
|
|
3.8s on its eleven siblings, which pushed the job past its timeout and got a
|
|
fully passing test run cancelled.
|
|
|
|
Callers must not set PRISMA_BINARY_CACHE_DIR. The prisma-client-py default
|
|
(~/.cache/prisma-python/binaries/<prisma-version>/<engine-version>) is already
|
|
keyed by both versions, so a cache entry can never be served to a run that
|
|
expects different binaries.
|
|
|
|
runs:
|
|
using: composite
|
|
steps:
|
|
- name: Resolve prisma-client-py version
|
|
id: version
|
|
shell: bash
|
|
run: |
|
|
version="$(grep -A1 '^name = "prisma"$' uv.lock | sed -n 's/^version = "\(.*\)"$/\1/p' | head -1)"
|
|
if [ -z "${version}" ]; then
|
|
echo "could not resolve the prisma package version from uv.lock" >&2
|
|
exit 1
|
|
fi
|
|
echo "version=${version}" >> "$GITHUB_OUTPUT"
|
|
|
|
- name: Restore Prisma binaries
|
|
uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0
|
|
with:
|
|
# ~/.cache/prisma-python holds the npm install tree prisma-client-py
|
|
# drives; ~/.cache/prisma is where @prisma/engines stages its downloads.
|
|
path: |
|
|
~/.cache/prisma-python
|
|
~/.cache/prisma
|
|
key: ${{ runner.os }}-prisma-binaries-${{ steps.version.outputs.version }}
|