-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
use github token if present when fetching org id #19244
use github token if present when fetching org id #19244
Conversation
client, err := b.Client("") | ||
var githubToken string | ||
if token, ok := data.GetOk("token"); ok { | ||
if t, ok := token.(string); ok { |
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.
We should add token
to the framework.FieldSchema
above in pathConfig()
. You can see an example of that here. If we do that then we can safely do the type assertion without this "if ok" pattern. Additionally, we will want to add token
to the API docs.
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 for taking this one on! This adds an interesting situation. Currently we require the token
on Login. But if the user has already configured this auth method with a token in the Config step then they might expect to not have to provide a token on Login. I think we should still require it on Login, but I am curious what others think.
@fairclothjm and I discussed this some more, we decided to keep the |
@raymonstah I am thinking it might be better to read an environment variable to get the token for writing the config. Adding the token as a new field on the config might cause confusion since this is just to fix an edge case that we are only aware of in the TFVP tests. The real solution for users is to set the org ID in the config. What do you think? |
@fairclothjm I think that makes much more sense. Thanks for the suggestion. |
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.
LGTM!
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.
Looks good! Had a quick q: is there a need to call it the VAULT_AUTH_GITHUB_TOKEN
if it's never actually being used for authentication? Was curious if this was just because of a precedent or if we can also name this GITHUB_TOKEN
to match up w/ what we already have in the TFVP. We can rename the TFVP environment variable as well, just wanted to bring up the question 😄 also tagging @fairclothjm for visibility
@vinay-gopalan I prefixed it with vault/builtin/credential/github/cli.go Line 27 in 861454e
|
Ah okay, I think that looks good; thanks for confirming @raymonstah! |
@raymonstah @vinay-gopalan I missed that Also, we are using I am wondering if we should use something different? Maybe |
JM that's a great callout and thanks for going the extra step to confirm the environment variables aren't already being used! I agree with you in that I don't have a strong preference, but I also see the value in adding the prefix since it's a precedent— |
@raymonstah FYI, we are going to backport this to 1.13, .12, and 1.11 so the TFVP tests are happy. Thanks again for this! |
When running our acceptance tests in other repos, we often hit the rate limit for GitHub's API. See https://github.com/hashicorp/terraform-provider-vault/actions/runs/3767881277/jobs/6405863202#step:5:349 as an example. This change takes in the Github token (if present) when creating the GH client so that we can make authenticated requests, which bumps the rate limit to 5k requests per hour, instead of the 60/hour that we're currently exceeding.