-
Notifications
You must be signed in to change notification settings - Fork 1.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
Remove Octokit::Client::Authorizations #1494
Conversation
# @param options [Hash] Header params for request | ||
# @return [Array<String>] OAuth scopes | ||
# @see https://developer.github.com/v3/oauth/#scopes | ||
def scopes(token = @access_token, options = {}) |
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.
It might be worth keeping this one? 🤔 It isn't specifically related to the Authorizations API and it could be useful for users. I'm not sure we have any replacement to it either, as I don't think there is a way to access headers in the SDK.
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.
Good point! Would you rather I keep the authorizations module around for this use case, or refactor this functionality somewhere else?
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.
Kinda up to you, honestly. I would probably move it ("authorizations" isn't really a sensible name, since I think it works for any token?).
5658816
to
2e251af
Compare
@timrogers Apologies for the force-push! It took me a minute to understand that vcr was reaching out to an actual endpoint and auto-generating failing cassettes when I first renamed the Authorizations module. Is this fix something like you had in mind? I've gone for |
lib/octokit/client/tokens.rb
Outdated
# @example Create a new OR return an existing authorization to be used by a specific client for user ctshryock's project Zoidberg | ||
# client = Octokit::Client.new(:login => 'ctshryock', :password => 'secret') | ||
# client.create_authorization({:idempotent => true, :client_id => 'xxxx', :client_secret => 'yyyy', :scopes => ["user"]}) | ||
def create_authorization(options = {}) |
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.
Why is this required to test #scopes
? That method looks like it should work with any token and get its permissions.
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.
In the test here an authorization is required to be created before checking its scopes.
Optionally, we could remove that method and also remove the testing for scopes, which doesn't feel ideal. I'm not seeing an easy way to keep a valid test of scopes without that method. Thoughts?
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.
Could we not just call #scopes
directly with a token, rather than creating one with #create_authorization
?
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.
Welllllll of course we could do that! Forgive my slowness, and please take another look!
I'm unsure of the proper Ruby practice around cassettes or how to autogenerate/remove them. The create_authorizations cassettes are now safe to remove so I've done so manually. |
918c928
to
8850326
Compare
@timrogers Do you think this is okay to merge after your update? |
Fixes #1429.
This PR should land in a breaking change as Tim noted in the above issue, even if the underlying APIs are no longer functional.