Release aborted - bad credentials

deployment
github-releases

#1

hi there,

I have a strange problem with a deploy. The job is https://travis-ci.org/EGI-Foundation/glite-info-update-endpoints/jobs/460371411

The error I’m seeing is :

/home/travis/.rvm/gems/ruby-2.4.1/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete': GET https://api.github.com/user: 401 - Bad credentials // See: https://developer.github.com/v3 (Octokit::Unauthorized)

It’s wierd, because this job has triggered deploys previously on releases. I suspect that since the credentials in the travis.yml do not belong to me, they were not exposed by the job.

Would this be a correct interpretation?

Would the solution to share them in the job configuration via the web interface then?

Thanks!
Bruce


#2

The private key that decrypts the secret belongs to the repository, so as long as the build happens on the correct repository, the deployment code will have access to the API token.

If the deployment is now failing, but was succeeding 2 months ago, then my first guess is that the token has since seen revoked by the token owner.


#3

Thanks very much!

I am waiting for confirmation on this from my colleague. I just wanted to sure that there are no other sources of this behaviour. Github has been moving away from Services and towards Apps. We are using the Travis.org integration for Github which, as far as I can tell, is a Github service. Is it possible that the Travis service is denied access to (the release) parts of the Github API? I highly doubt this, but want to ask for future reference.

Thanks!


#4

Our deployment happens outside of the direct GitHub integration points (neither Services nor Apps is involved here). In the case of GitHub Releases, it is carried out with relevant git commands and GitHub Releases API using their Ruby client. If deployment is denied, it is due to the wrong credentials your deployment is providing. I do not think we changed anything in the time frame you mentioned, thus I am inclined to think that the change came from the token’s validity.