fix(ci): scope backend codegen to the Python stubs so Test Backend has a buf-free path - #189
Conversation
…s a buf-free path Root `make generate` ends with `$(MAKE) -C services/analytics generate`, and that target runs `cd ../../proto && buf generate`. The backend test job installs only Python, so its `make generate` step failed with `/bin/sh: 1: buf: not found`. It went unnoticed because backend.yml is path-filtered on `services/backend/**` plus itself, and no PR had touched either since the analytics tail landed. Split the root target by language: `generate-backend` (grpcio-tools' bundled protoc) and `generate-analytics` (buf). `generate` keeps calling both, so the documented local regenerate-everything entry point is unchanged. Both the CI job and `make test-backend` now depend on `generate-backend`. Moving only the CI side would have broken the local-equals-CI invariant (Makefile `ci` target, AGENTS.md, docs/ci.md) in the opposite direction: local backend tests would still require buf where CI no longer does. The backend never consumed the Go stubs - it imports `app/proto_gen` only. Docs that walk a reader through the Python-only path (backend README, running-tests, the gRPC exercise's Python fallback) now name the target that matches what they describe.
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Root
make generateends with$(MAKE) -C services/analytics generate, and that target runscd ../../proto && buf generate. The backend test job installs only Python, so itsmake generatestep failed with/bin/sh: 1: buf: not found. It went unnoticed because backend.yml is path-filtered onservices/backend/**plus itself, and no PR had touched either since the analytics tail landed.Split the root target by language:
generate-backend(grpcio-tools' bundled protoc) andgenerate-analytics(buf).generatekeeps calling both, so the documented local regenerate-everything entry point is unchanged.Both the CI job and
make test-backendnow depend ongenerate-backend. Moving only the CI side would have broken the local-equals-CI invariant (Makefilecitarget, AGENTS.md, docs/ci.md) in the opposite direction: local backend tests would still require buf where CI no longer does.The backend never consumed the Go stubs - it imports
app/proto_genonly. Docs that walk a reader through the Python-only path (backend README, running-tests, the gRPC exercise's Python fallback) now name the target that matches what they describe.