Protocol Buffers
Overview
All Michelangelo API resources are defined in .proto files. The gRPC API, message types, and service contracts all live here. Proto files are the source of truth for what resources exist, what fields they have, and what operations the API server supports.
Module Structure
proto/api/v2/— source of truth for all service and message definitionsproto-go/— generated Go bindings, never edit directly- Proto files are organized per resource type:
pipeline_svc.proto,project_svc.proto, etc.
The proto-go/ directory is checked into the repo for convenience (so Go tools can consume the bindings without running Bazel), but it is always derived from proto/api/v2/. Any manual edits to proto-go/ will be overwritten by the next code generation run.
Code Generation Workflow
After editing any .proto file, regenerate the Go bindings:
- If creating a new service: scaffold the proto file with
tools/grpc-svc-gen.sh [Entity], then edit the generated file. Otherwise, edit the existing.protofile inproto/api/v2/directly. - Run
tools/gazelleto update BUILD targets - Run
bazel build //proto/...to compile - Run
tools/gen-proto-go.shto regenerate aliasBUILD.bazelfiles underproto-go/, sync dependency versions fromgo/go.modintoproto-go/go.mod, and rungo mod tidyinproto-go/ - Check in both the
.protochanges and the generatedproto-go/changes
Service Pattern
Each ML entity (Pipeline, InferenceServer, Model, etc.) has a corresponding *_svc.proto file that defines a gRPC service with standard CRUD methods. For example, pipeline_svc.proto defines PipelineService with CreatePipeline, GetPipeline, ListPipelines, UpdatePipeline, and DeletePipeline RPCs.
When adding a new API resource, follow this same pattern. The new entity gets its own *_svc.proto file in proto/api/v2/.
gRPC Service Generation
Use tools/grpc-svc-gen.sh to scaffold a new service rather than copying and editing an existing file by hand:
tools/grpc-svc-gen.sh [EntityName]
Example:
tools/grpc-svc-gen.sh Pipeline
Run the script without arguments to see its full usage message.
Versioning
All current APIs live under proto/api/v2. Breaking changes (field removals, type changes, incompatible method signature changes) require a new version directory (e.g., proto/api/v3). Additive changes (new fields, new RPCs) can go into the existing version.