Reputation: 19808
We're starting to use gRPC and are currently using bazel
as our build tool. After an engineer pulls in updates to proto definitions, they'll need to proto compile. Due to the structure of our repository, the proto compile targets will be scattered in the repo.
The only option I'm seeing is to use a target naming convention so engineers just need to do something like bazel build //...:compile-proto
. Are there other ways to make it easy for engineers to proto compile all updated proto definitions?
Upvotes: 5
Views: 6043
Reputation: 3868
If you add a specific tag to each of them, you can use --build_tag_filters.
For example:
a_proto_library(
name = "compile-proto",
tags = ["a_proto"],
[...]
)
and then bazel build --build_tag_filters=a_proto //...
.
You can also wrap the rule in a macro to add the tag automatically.
Upvotes: 6
Reputation: 5026
I don't think //...:compile-proto
is a valid target pattern, so unfortunately I'm not sure that that would work (not that you necessarily really want to rely on naming conventions anyway). See https://docs.bazel.build/versions/main/guide.html#specifying-targets-to-build
One option is to let bazel do all the updating for you. If you're already doing builds like bazel build //...
to build everything, then once you pull in updates to proto definitions, another bazel build //...
should rebuild only what has changed.
Another option is to find all rules using bazel query:
https://docs.bazel.build/versions/main/query.html
https://docs.bazel.build/versions/main/query-how-to.html
https://docs.bazel.build/versions/main/query.html#kind
Something like:
targets=$(bazel query "kind('java_proto_library', //...)")
bazel build $targets
Note that query with //...
will load every build file in the workspace, but not build anything.
Upvotes: 2