tree: c4851f3c590f0067f743b81676238e9d7537a16e [path history] [tgz]
  1. README.md
  2. __init__.py
  3. compile_build_api_proto.py
  4. contrib/
  5. controller/
  6. field_handler.py
  7. field_handler_unittest.py
  8. gen/
  9. proto_compiled_unittest.py
  10. router.py
  11. router_unittest.py
  12. validate.py
  13. validate_unittest.py
api/README.md

Build API

Welcome to the Build API.

chromite/infra/proto/

This directory is a separate repo that contains all of the raw .proto files. You will find message, service, and method definitions, and their configurations. You will need to commit and upload the proto changes separately from the chromite changes.

  • chromite/api/ contains the Build API services.
    • Except chromite/api/build_api.proto, which contains service and method option definitions.
  • chromiumos/ generally contains more sharable proto.
    • chromiumos/common.proto contains well shared messages.

This repo was and will be pinned to a specific revision in the manifest files when we get closer to completing work on the Build API. For the speed we're moving at now, though, having that revision pinned and updating the manifest has caused far more problems than its solving.

When we do go back to the pinned revision:

  1. Commit and land your proto changes.
  2. Update manifest/full.xml with the new revision.
  3. Update manifest-internal/external-full.xml with the new revision.
  4. Run chromite/api/compile_build_api_proto.
  5. Upload the changes from the previous three steps and add CQ-DEPEND between the CLs.

gen/

The generated protobuf messages.

Do not edit files in this package directly!

The proto can be compiled using the compile_build_api_proto script in the api directory. The protoc call is executed inside the chroot to ensure a standard protoc version is used.

controller/

This directory contains the entry point for all of the implemented services. The protobuf service module option (defined in build_api.proto) references the module in this package. The functions in this package should all operate as one would expect a controller to operate in an MVC application - translating the request into the internal representation that's passed along to the relevant service(s), then translates their output to a specified response format.