Skip to content
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

.authenticate() does not fail when github token is for user that has not gone through OAuth flow for travis-pro #17

Open
travi opened this issue Jan 15, 2017 · 0 comments

Comments

@travi
Copy link

travi commented Jan 15, 2017

I finally solved an issue that wasted far more time than it should have, considering how simple the fix was. It turns out that I had never logged into travis-pro with the account that the github token was tied to, so I had never granted the travis-pro app access to that github account. Had the .authenticate() call failed due to the lack of required permissions, as the readme suggests that it would, I hope that I would have narrowed in on the problem sooner.

Authentication is simply a convenience function that ensures your token has the required permissions, then appends your access_token to all subsequent requests.

For context, I was trying to configure semantic-release to work with travis-pro and was getting {file: 'not found'} responses. These responses were because the access token did not give the account the necessary access to the travis-pro api. Tokens from other accounts that had the same github scopes (repo) worked just fine. Once I logged into travis-pro with this account and granted travis-pro access to that account, the token started working with no other changes.

Also worth noting is the fact that we still have never logged into the public travis instance (travis-ci.org), but have been successful with the semantic-release process for public repos. This appears to be a difference in behavior between the apis for public travis vs travis-pro.

Would it be possible to detect this scenario and fail the .authenticate() step? If not, it may help someone in the future to at least update the protip in the readme to make it clear that it doesnt fully "ensures your token has the required permissions", highlighting this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant