-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tonic-health: commit generated code #1065
tonic-health: commit generated code #1065
Conversation
This saves users from needing protoc available on their path if they're not generating other tonic code at build time, either. The generated modules can be regenerated by enabling the `gen-proto` feature, which will trigger the relevant part of the build script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for getting this started. I left a comment about doing the gen in a test. I think we should make that change then we can merge.
tonic-health/build.rs
Outdated
@@ -1,11 +1,15 @@ | |||
use std::env; | |||
use std::path::PathBuf; | |||
// This build file is used to generate the code as a one-off, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For prost-types
we generate the code via a bootstrap test. This test runs on CI and verifies that the generated code checked in matches locally generated code on the ci box. This removes the need for an awkward feature and gives you the CI check automatically. You can see that approach here https://github.com/tokio-rs/console/blob/606cf721bdd831ee4fa8622081a654fa5b1926b8/console-api/tests/bootstrap.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that makes sense, I see now. I've pushed a commit to do it the same way here, thanks for the pointer.
As suggested by @LucioFranco in https://github.com/hyperium/tonic/pull/1065\#discussion_r951580189. This avoids the need for a feature which would show up in docs.rs, and achieves the same goals via CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
As suggested by @LucioFranco in hyperium#1068 (comment). This avoids the need for consumers to have `protoc` in their path. Implemented following changes in hyperium#1065.
* types: add tonic as dependency, add error_details.proto * types: add BadRequest support from flemosr/tonic-richer-error * types: adjust code following suggestions Adjustments following suggestions by @LucioFranco in #1068. Adjust style, remove unecessary prints, avoid glob imports, apply `non_exhaustive` to `ErrorDetails` and `ErrorDetail`, avoid pub fields in `ErrorDetails`, adjust `WithErrorDetails::with_error_details_vec` args, add `gen_details_bytes`. * types: add generated protobuf code As suggested by @LucioFranco in #1068 (comment). This avoids the need for consumers to have `protoc` in their path. Implemented following changes in #1065. * types: add custom metadata support This allows consumers to provide custom metadata when creating a `Status` with error details. * types: adjust code following suggestions Adjustments following suggestions by @LucioFranco in #1068. Move `error_details_vec` mod into `error_details` mod, adjust doc comments, rename `WithErrorDetails` trait to `StatusExt`.
This PR resolves #1052 by making the build.rs code and tonic-build dependency optional, as suggested by @nashley in the comments of that issue.
Motivation
See #1052. In brief, this avoids consumers having to have a
protoc
binary available in order to usetonic-health
, which is helpful if they have also committed their generated code.Solution
src/generated