You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.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.The text was updated successfully, but these errors were encountered: