To generate/update BUILD.bazel files for any particular client or a batch of clients:
```
bazel run //:build_gen -- --src=google/example/library
```
PiperOrigin-RevId: 286958627
1) Update to latest gapic-generator (has iam resource names fix for java).
2) Fix non-trivial issues with oslogin (resources defined in sibling package to the one they are used from) and monitoring.
3) Fix trivial missing dependencies in proto_library targets for other apis.
This is to prepare the repository to being populated with BUILD.bazel files for all supported apis (101 API) in all 7 languages.
PiperOrigin-RevId: 281618750
This makes googleapis forward compatible with Bazel incompatible change https://github.com/bazelbuild/bazel/issues/8922.
This CL was created by adding @rules_proto to the WORKSPACE file and then running:
find . -name BUILD.bazel | \
while read build; do \
buildifier --lint=fix --warnings=load $build; \
done
Since buildifier cannot be told not to reformat the BUILD file, some files are reformatted.
PiperOrigin-RevId: 280356106
Also configure python build for the following clients as an example:
diaglogflow/v2
language/v1
texttospeech/v1
firestore/v1beta1
pubsub/v1
PiperOrigin-RevId: 279406526
Update gapic-generator and protoc-java-resource-name plugin dependencies to the latest versions.
The following clients remain broken because of bugs in gapic-generator and/or corresponding configs
google/cloud/iot/v1
google/cloud/oslogin/v1
google/spanner/admin/instance/v1
google/cloud/oslogin/v1
PiperOrigin-RevId: 279171061
0) This clenup is necessary in the context of bazel-based gapic codegen work.
1) Partially the #273 PR was rolled back in #298, which made the remaining parts broken anyways (for example monitoring `BUILD` file reffers to rpc and annotations targets, which were removed in #298).
2) The `.gitmodules` point to 2 year old repository commits, boringssl link is broken.
Note, as part of bazel codegen integration this repository (googleapis) will be populated with corresponding `BUILD.bazel` files (NOT part of this commit), which may potentially break teams which import googelapis as new github repo (using `new_git_repository` workspace rule) and then overlay their custom build files on top of it.
To fix that the teams which currently overlay custom build files on googleapis packages are expected to migrate to using the provided `BUILD.bazel` files instead (they should contain everything needed, like `proto_library`, `java_proto_library`, etc. definitions). In case if something is missing, it should be added directly to the `BUILD.bazel` files provided in googleapis, instead of overlaying custom build files.
Practically, for teams which currently rely on custom build files, this means switching from `new_git_repository` to `git_repository` in their WORKSPACE file definitions, then fixing target naming differences (if any) and transferring missing stuff (if any) from custom `BUILD` files to googleapis' `BUILD.bazel` files.
* WORKSPACE and BUILD for bazel support
* added google/protobuf BUILD file and protos
* more cleanup
* added bazel support to readme
* removed local copy of .bzl files
Using the grpc's bzl files
Cleaned up WORKSPACE
Formated BUILD files
* removed local copy of google/protobuf
Modified grpc skylark files to use protobuf submodule's
copies of the well known protos.
Google APIs
michaelbausor
Vadym Matsishevskyi
makdharma