GET https://api.github.com/user: 401 - Bad credentials

Travis CI Discussions & Feedback
#1

I have been connecting Travis CI to build automatically in one of my GitHub repos. Currently, my Travis CI build is successful. However, I notice the following message in that succesful build:

Skipping a deployment with the releases provider because this repo's name does not match one specified in .travis.yml's deploy.on.repo: HughParsonage/latex-travis

I suspect this is because I followed an example .travis.yml online and so the deployed repo is still pointing to another repository (HughParsonage/latex-travis). So, I simply changed the last line of my .travis.yml file to deploy the repo to the my intended GitHub repo (lindsayrutter/ggenealogy). Doing so then caused my Travis CI build to fail with the following message:

GET https://api.github.com/user: 401 - Bad credentials

For the time being, I switched the last line of my .travis.yml file to point to the unrelated GitHub repo just so the build will pass. However, I assume I should eventually have this last line pointed to the correct repo (lindsayrutter/ggenealogy).

I should state that the repository used to be called lrutter/ggenealogy. However, I feel I have updated this thoroughly. Upon Internet search, I see similar problems here and there, and only one GitHub issues forum with this topic but I am not understanding the suggestions and many of the links are broken.

How should I attempt to fix the error above when pointed to my repository? Thank you for sharing ideas.

#2

https://docs.travis-ci.com/user/deployment/releases shows you how to generate the encrypted string for your GitHub API key that is suitable for your deployment. (You may also opt in to testing the next-generation deployment too. See https://docs.travis-ci.com/user/deployment-v2 .)

If you remove it, it would be assumed “this repo”, so explicitly specifying it is for explicitly preventing others (forks) from triggering deployment.

1 Like
#3

Hello @BanzaiMan. Thank you for your help. I tried your suggestion (creating a GitHub API key) following the instructions on the site you recommended and using the command travis setup releases --force.

Indeed, this seemed to rewrite the api_key secure field in my .travis.yml file. Unfortunately, upon submitting this change to GitHub, I still receive the error on my Travis CI Build:

/home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in 'on_complete': GET https://api.github.com/user: 401 - Bad credentials as seen here.

However, the other aspect of my travis build ("continuous-integration/travis-ci/push") succeeded as seen here.

In case it is related, I was also unsure what to use for my deploy file in my .travis.yml file. I currently just typed in the field as “.travis.yml”.

It seems my travis build is half working now. I am using travis CI because I am resubmitting this package to CRAN and was asked to check that it passed on Linux. So, I assume this error on my Travis CI Branch still needs to be fixed. I am not sure what may be the issue for this error still remaining? Do you have any suggestions on things I should check for? Thank you again for sharing your advice.

#4

OK. I see the problem now. You have enabled your builds on both travis-ci.org (https://travis-ci.org/lindsayrutter/ggenealogy/builds?utm_medium=notification&utm_source=github_status) and travis-ci.com (https://travis-ci.com/lindsayrutter/ggenealogy/builds/) with GitHub Apps. The CLI commands work with the .org API endpoint by default, so the data you have is valid for .org but not .com.

I suggest disabling .org, and use the GitHub Apps going forward. See https://docs.travis-ci.com/user/deployment/releases#using-travis-ci-client-to-populate-initial-deployment-configuration.

An aside: GitHub Releases generally works with tags, so you’d want to make sure that this would fit your workflow. https://travis-ci.org/lindsayrutter/ggenealogy/builds/657769342?utm_medium=notification&utm_source=github_status succeeded, but it was triggered by a non-tag build, and GitHub created a release with a randomized name https://github.com/lindsayrutter/ggenealogy/releases/tag/untagged-b6de7df81029a5788ce3.

1 Like
#5

Hello @BanzaiMan. Thanks for the suggestion to use the Travis CI command line client to configure the .travis.yml file. I tried now issuing the command:

travis setup releases --com --force

This process did seem to change my api_key in my .travis.yml file. I am now receiving the opposite problem upon pushing to GitHub. That is, my “Travis CI Build” is successful, but my “continuous-integration/travis-ci/push” is unsuccessful as seen here.

I am not sure if this is what you suggested to do to at least get rid of the error? Or, is there a specific procedure to “disable .org” as you suggested? (besides running --com option in travis setup). Thank you very much again for your help.

#6

Go to https://travis-ci.org/account/repositories, and find your repo there.

1 Like
#7

I had a similar problem at the deploy process to heroku provider:

API request failed. Message: Invalid credentials provided.

Until now, I had configured HEROKU Environment Variable in Travis panel with heroku api key, and I used it in my travis.yml to configure the deploy.

deploy:
  provider: heroku
  api_key:
    secure: $HEROKU
...

At march 2 I started to have this error, the only thing that worked for we was, install travis cli, encrypt the heroku api-key and add it encrypted to my travis.yml

travis encrypt <api_key> --add deploy.api_key

deploy:
  provider: heroku
  api_key:
    secure: encypted_key...
...

Is it no longer possible to use environment variables to have credentials hidden there?

#8

Was your $HEROKU value plain, or encrypted? If it was plain and if it was working, it seems accidental; we would not have had access to $HEROKU value when configuring the build, and it was working because we passed through secure value without validation (it should be decrypted before it’s passed on to the next component in the system).

It stopped working because we are now doing more to ensure that configuration is correct and workable:


And your new configuration works, because it is valid. (I’d think that api_key: $HEROKU key-value pair should have worked, but I’m saying this from memory.)

1 Like
Release aborted - bad credentials
Imprint