feat(cli-engine): send deploy source and client headers to the Management API - #257
feat(cli-engine): send deploy source and client headers to the Management API#257gregory-boch-prisma wants to merge 2 commits into
Conversation
…ment API The Management API records where each Compute deploy came from in its analytics. Every request from the engine's Management API client now carries: - x-prisma-client-name: prisma-cli - x-prisma-client-version: the CLI version - x-prisma-deploy-source: github-action when GITHUB_ACTIONS is "true", otherwise cli The API behaves the same with or without them. The version reaches the engine through a new optional cliVersion field on ManagementApiClientConfig, so hosts that do not set it keep working. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Essentials Run ID: 📒 Files selected for processing (5)
Included review availability: 2 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. Summary by CodeRabbit
WalkthroughThe management API client now adds CLI name, optional CLI version, and deploy-source headers to requests. The deploy source is Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to CLI requests receive the intended identification headers while preserving behavior when no CLI version is available. No actionable merge risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
commit: |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Problem
The Management API records Compute deploys in its analytics, but it cannot tell which tool sent a request or whether it ran in GitHub Actions. The CLI's requests carry only the runtime's default User-Agent (
nodeorBun/x.y.z), which any Node or Bun script also sends.Change
Every request from the engine's Management API client (
ctx.api) now carries three headers:x-prisma-client-nameprisma-clix-prisma-client-versiongetCliVersion()x-prisma-deploy-sourcegithub-actionwhenGITHUB_ACTIONSis"true", otherwiseclionRequestmiddleware onsdk.client, the same way the SDK addsAuthorization.cliVersionfield onManagementApiClientConfig. A host that does not set it simply omitsx-prisma-client-version.ctx.apicarries Composer's build reports duringprisma deployand theprisma servicecommands, so both are covered.@prisma/cli-engineis bumped from 0.3.0 to 0.3.1 withpnpm bump-cli-engine-version patch, because published engine versions cannot change.The headers change analytics only. The API behaves the same with or without them, and they carry no user data: just the tool name, its version, and whether the run is in GitHub Actions.
The server side is prisma/pdp-control-plane#5284. A matching change for Composer's alchemy client covers the deployment create and start calls, which do not go through
ctx.api.Verification
pnpm typecheckandpnpm lintare clean.pnpm --filter @prisma/cli-engine test: 830 passed. New tests check the headers inside and outside GitHub Actions, and thatx-prisma-client-versionis left out whencliVersionis not set. They go through the real client with a stubbedfetch.pnpm --filter @prisma/cli test: 964 passed, 2 skipped.bin.test.tsnow expectscliVersionin the assembled config.pnpm --filter @prisma/compute test: 11 passed.🤖 Generated with Claude Code