[Fix] Pin Prisma Node.js dependency in CI workflows#24696
Conversation
prisma generate internally runs `npm install [email protected]` against the npm registry at runtime. Without a bundled Node.js, this causes ECONNRESET failures on flaky GitHub Actions network and leaves the npm transitive dependency tree unpinned. Pre-install nodejs-wheel-binaries==24.13.1 (matching the Dockerfiles) so prisma uses the bundled Node/npm instead of fetching from the registry. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR fixes flaky CI failures caused by Confidence Score: 5/5Safe to merge — targeted infrastructure fix with no production code changes and no regressions. All changed lines are CI workflow YAML. The fix is well-motivated, consistent with existing Dockerfile practice, and the only finding is a P2 style inconsistency (missing PRISMA_BINARY_CACHE_DIR on the migration step). Per confidence guidance, P2-only findings default to 5/5. No files require special attention; the minor PRISMA_BINARY_CACHE_DIR inconsistency in test-proxy-e2e-azure-batches.yml is non-blocking.
|
| Filename | Overview |
|---|---|
| .github/workflows/test-litellm-matrix.yml | Pre-installs nodejs-wheel-binaries==24.13.1 and sets PRISMA_BINARY_CACHE_DIR before prisma generate; consistent with Dockerfile approach and fixes flaky ECONNRESET failures. |
| .github/workflows/test-proxy-e2e-azure-batches.yml | Same nodejs-wheel-binaries fix applied to the Generate Prisma client step; minor inconsistency: PRISMA_BINARY_CACHE_DIR is not propagated to the subsequent prisma migrate deploy step. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[CI: Generate Prisma client step] --> B{Before fix}
A --> C{After fix}
B --> D[prisma generate invoked]
D --> E[prisma detects no Node.js in venv]
E --> F[Falls back to nodeenv]
F --> G[Downloads Node.js from internet]
G --> H{npm registry reachable?}
H -- Yes --> I[npm install [email protected] succeeds]
H -- No --> J[ECONNRESET / flaky failure]
C --> K[pip install nodejs-wheel-binaries==24.13.1]
K --> L[prisma generate invoked]
L --> M[prisma detects nodejs-wheel-binaries in venv]
M --> N[Uses bundled Node.js + npm locally]
N --> O[prisma generate succeeds reliably]
Comments Outside Diff (1)
-
.github/workflows/test-proxy-e2e-azure-batches.yml, line 77-83 (link)PRISMA_BINARY_CACHE_DIRnot set forprisma migrate deployThe
Generate Prisma clientstep setsPRISMA_BINARY_CACHE_DIR: ${{ runner.temp }}/prisma-cache, but the subsequentRun Prisma migrationsstep (prisma migrate deploy) does not. This is inconsistent — if Prisma downloads any engine binaries during migration, it won't use the pinned cache path for that step.In practice this is likely benign because
nodejs-wheel-binaries(installed in the venv in the prior step) is the main mechanism preventing runtime npm downloads, and the venv persists across steps in the same job. For full consistency, consider adding the samePRISMA_BINARY_CACHE_DIRenv var to theRun Prisma migrationsstep as well.
Reviews (1): Last reviewed commit: "Pin nodejs-wheel-binaries in CI workflow..." | Re-trigger Greptile
Summary
Failure Path (Before Fix)
prisma generateinternally runsnpm install [email protected]against the npm registry at runtime. In CI, there is no pre-installed Node.js, so prisma falls back tonodeenvwhich downloads Node, then runs an unpinnednpm install. This causes:ECONNRESETerrors from flaky npm registry connections on GitHub Actions runnersFix
Pre-install
nodejs-wheel-binaries==24.13.1(a Python package that bundles Node.js + npm locally) before runningprisma generate. This matches the approach already used in the Dockerfiles. When prisma detectsnodejs-wheel-binariesis available, it uses the bundled Node/npm instead of downloading from the internet.Testing
Dockerfile.non_root) already usenodejs-wheel-binaries==24.13.1withprisma==0.11.0nodejs-wheel-binariesbefore falling back tonodeenv/global npmType
🐛 Bug Fix
🚄 Infrastructure