-
Notifications
You must be signed in to change notification settings - Fork 375
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
feat(generator): add "generator" to API client header "gccl" semver #7383
Conversation
1. Strip the leading "v" from the value of the "gccl" component in the `X-Goog-Api-Client` header so that what remains is a valid semantic version string (see https://semver.org/). 2. Add a "generator" build identifier to the "gccl" semvar for requests sent from generated clients. The upshot is that the library-version component of the client header will be "gccl/<major>.<minor>.<patch>+<git-hash>.generator", allowing us to identify requests from generated clients.
Google Cloud Build Logs
ℹ️ NOTE: Kokoro logs are linked from "Details" below. |
Codecov Report
@@ Coverage Diff @@
## main #7383 +/- ##
=======================================
Coverage 93.64% 93.65%
=======================================
Files 1351 1351
Lines 117315 117334 +19
=======================================
+ Hits 109865 109885 +20
+ Misses 7450 7449 -1
Continue to review full report at Codecov.
|
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.
Make sure you edit the commit message to s/semvar/semver/
Resume sending the leading "v" in the value of the "gccl" component of the `X-Goog-Api-Client` header (see googleapis#7383). The Cloud Spanner frontend's route lookup service uses the version string in a semver comparison to determine how the request should be routed, and it currently expects to see a literal "v". (For the record, the minimal version supported by the route lookup service is "v1.17.1".) Changing the route lookup service to not care about the leading "v" is non-trivial (it uses a single-value map, indexed by language, to store the minimum supported version, and the value comes from a flag), and even then the fix will take some time to roll out, so, in the meantime, we revert to sending the "v". Eventually eliminating the "v" is still a goal because it makes the header conform to the specification, and it also makes C++ behave like the other languages.
) Resume sending the leading "v" in the value of the "gccl" component of the `X-Goog-Api-Client` header (see #7383). The Cloud Spanner frontend's route lookup service uses the version string in a semver comparison to determine how the request should be routed, and it currently expects to see a literal "v". (For the record, the minimal version supported by the route lookup service is "v1.17.1".) Changing the route lookup service to not care about the leading "v" is non-trivial (it uses a single-value map, indexed by language, to store the minimum supported version, and the value comes from a flag), and even then the fix will take some time to roll out, so, in the meantime, we revert to sending the "v". Eventually eliminating the "v" is still a goal because it makes the header conform to the specification, and it also makes C++ behave like the other languages.
Strip the leading "v" from the value of the "gccl" component in the
X-Goog-Api-Client
header so that what remains is a valid semanticversion string (see https://semver.org/).
Add a "generator" build identifier to the "gccl" semver for requests
sent from generated clients.
The upshot is that the library-version component of the client header
will be
gccl/<major>.<minor>.<patch>+<git-hash>.generator
, allowingus to identify requests from generated clients.
This change is