-
Notifications
You must be signed in to change notification settings - Fork 35
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
Set User-Agent header in client #256
Conversation
3ece3d4
to
bd95cd9
Compare
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.
This looks like a good addition so we can track usage of versions.
Some tests are failing though
Yesterday we had an acceptance spec failure caused by the test org not being cleaned properly, and I manually deleted a lingering pipeline. It's possible rebasing this on main (to get the merged GET body fix) and triggering a new build might Just Work. |
bd95cd9
to
74f3e01
Compare
18a51bd
to
a98f3ca
Compare
I don't think it's a deal breaker in the short term, but looking at the user agents we're logging in production now it seems like maybe this only sets it for REST API calls, and not for graphql ones? |
Actually yes @yob that is correct. I'll create another task to do this for graphql as well |
In #256 we starting setting a custom User-Agent header on REST API calls, to help us understand the ways our API is used. It looks like this: Terraform/ (+https://www.terraform.io) Terraform-Plugin-SDK/2.0.3 buildkite/0.15.0 This builds on that work and sets the same User-Agent on graphql API requests as well. It drops the unnescary use of golang.org/x/oauth2 to set a static bearer token header, and uses the tripperware pattern [1] to set both headers we care about: 1. the static bearer token for auth 2. the user agent The same http.Client is used for both REST and graphql, so we'll get identical behaviour on both APIs. [1] https://dev.to/stevenacoffman/tripperwares-http-client-middleware-chaining-roundtrippers-3o00
In #256 we starting setting a custom User-Agent header on REST API calls, to help us understand the ways our API is used. It looks like this: Terraform/ (+https://www.terraform.io) Terraform-Plugin-SDK/2.0.3 buildkite/0.15.0 This builds on that work and sets the same User-Agent on graphql API requests as well. It drops the unnecessary use of golang.org/x/oauth2 to set a static bearer token header, and uses the tripperware pattern [1] to set both headers we care about: 1. the static bearer token for auth 2. the user agent The same http.Client is used for both REST and graphql, so we'll get identical behaviour on both APIs. [1] https://dev.to/stevenacoffman/tripperwares-http-client-middleware-chaining-roundtrippers-3o00
In #256 we starting setting a custom User-Agent header on REST API calls, to help us understand the ways our API is used. It looks like this: Terraform/ (+https://www.terraform.io) Terraform-Plugin-SDK/2.0.3 buildkite/0.15.0 This builds on that work and sets the same User-Agent on graphql API requests as well. It drops the unnecessary use of golang.org/x/oauth2 to set a static bearer token header, and uses the tripperware pattern [1] to set both headers we care about: 1. the static bearer token for auth 2. the user agent The same http.Client is used for both REST and graphql, so we'll get identical behaviour on both APIs. [1] https://dev.to/stevenacoffman/tripperwares-http-client-middleware-chaining-roundtrippers-3o00
This sets the user agent for api client.
Using Provider.UserAgent to set the header.
Also, this can now take a
version
coming from ldflags which is added as a suffix.Rendered example: