# Release aborted - bad credentials

**URL:** <https://travis-ci.community/t/release-aborted-bad-credentials/1089>\
**Category:** Deployment\
**Tags:** deployment, github-releases\
**Created:** [November 27, 2018, 5:47pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089 "2018-11-27T17:47:48Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![brucellino](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/brucellino/32/143_2.png) [@brucellino](https://travis-ci.community/u/brucellino)\
**Post date:** [November 27, 2018, 5:47pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/1 "2018-11-27T17:47:48Z")

</div>

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](https://travis-ci.org/EGI-Foundation/glite-info-update-endpoints/jobs/460371411)

The error I’m seeing is :

```auto
/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

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 27, 2018, 7:11pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/2 "2018-11-27T19:11:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![brucellino](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/brucellino/32/143_2.png) [@brucellino](https://travis-ci.community/u/brucellino)\
**Post date:** [November 28, 2018, 4:14am UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/3 "2018-11-28T04:14:56Z")

</div>

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](http://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!

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 28, 2018, 3:07pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/4 "2018-11-28T15:07:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nguoianphu](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/nguoianphu/32/2267_2.png) [@nguoianphu](https://travis-ci.community/u/nguoianphu)\
**Post date:** [March 6, 2020, 8:42am UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/5 "2020-03-06T08:42:48Z")

</div>

Hi all,

My build is having same error. But I haven’t changed `.travis.yml` nor Github token.

Passed build (old, 7 months ago): [https://travis-ci.org/nguoianphu/cordova-builder/builds/562533817](https://travis-ci.org/nguoianphu/cordova-builder/builds/562533817)

Comparing the build logs show us the difference version of `dpl-releases`. The passed build had `dpl-releases-1.10.12`, while the failure has `dpl-releases-1.10.15`.

Failure build: [https://travis-ci.org/nguoianphu/cordova-builder/builds/659026968#L3330](https://travis-ci.org/nguoianphu/cordova-builder/builds/659026968#L3330)

```
Installing deploy dependencies
Successfully installed multipart-post-2.1.1
...
Parsing documentation for dpl-releases-1.10.15
Installing ri documentation for dpl-releases-1.10.15
Done installing documentation for multipart-post, faraday, public_suffix, addressable, sawyer, octokit, mime-types-data, mime-types, dpl-releases after 4 seconds
9 gems installed
/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)
	from /home/travis/.rvm/gems/ruby-2.4.1/gems/faraday-0.15.4/lib/faraday/response.rb:9:in `block in call'
	from /home/travis/.rvm/gems/ruby-2.4.1/gems/faraday-0.15.4/lib/faraday/response.rb:61:in `on_complete'
...
	from /home/travis/.rvm/gems/ruby-2.4.1/bin/dpl:23:in `<main>'
Preparing deploy
failed to deploy
```

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [March 6, 2020, 1:24pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/6 "2020-03-06T13:24:12Z")

</div>

> <https://github.com/nguoianphu/cordova-builder/blob/f3d9cb713ab086e126a36ef39bf70e9010d5fc3c/.travis.yml#L81>

Your problem is explained here.

> [@GET https://api.github.com/user: 401 - Bad credentials](https://travis-ci.community/t/get-https-api-github-com-user-401-bad-credentials/7424/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 v…

---

<div class="post-metadata">

**Author:** ![nguoianphu](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/nguoianphu/32/2267_2.png) [@nguoianphu](https://travis-ci.community/u/nguoianphu)\
**Post date:** [March 8, 2020, 10:54am UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/7 "2020-03-08T10:54:33Z")

</div>

Great! Thank you @BanzaiMan. My probelm is solved. 🙂

---

<div class="post-metadata">

**Author:** ![MatiasVara](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/matiasvara/32/4463_2.png) [@MatiasVara](https://travis-ci.community/u/MatiasVara)\
**Post date:** [April 26, 2020, 3:11pm UTC](https://travis-ci.community/t/release-aborted-bad-credentials/1089/8 "2020-04-26T15:11:57Z")

</div>

Hello, I am having a similar issue at [https://travis-ci.org/github/torokernel/torokernel](https://travis-ci.org/github/torokernel/torokernel). I wonder if it is the same problem. I am currently using github tokens for the deployment which is passed as an environment variable to Travis. Do I need to encrypt such token before set it as an env variable ? Or I am missing something.
