Release uploads, but job fails with weird error

/home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete’: GET 401 - Bad credentials // See: (Octokit::Unauthorized)

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/response.rb:9:in `block in call’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/response.rb:61:in `on_complete’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/response.rb:8:in `call’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/middleware/follow_redirects.rb:61:in `call’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/rack_builder.rb:143:in `build_response’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/connection.rb:387:in `run_request’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/faraday-0.15.4/lib/faraday/connection.rb:138:in `get’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/sawyer-0.8.1/lib/sawyer/agent.rb:94:in `call’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/connection.rb:154:in `request’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/connection.rb:19:in `get’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/client/users.rb:34:in `user’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-releases-1.10.8/lib/dpl/provider/releases.rb:58:in `user’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-releases-1.10.8/lib/dpl/provider/releases.rb:83:in `setup_auth’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-releases-1.10.8/lib/dpl/provider/releases.rb:87:in `check_auth’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/lib/dpl/provider.rb:187:in `block in deploy’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/lib/dpl/cli.rb:41:in `fold’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/lib/dpl/provider.rb:186:in `deploy’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/lib/dpl/cli.rb:32:in `run’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/lib/dpl/cli.rb:7:in `run’

from /home/travis/.rvm/gems/ruby-2.4.5/gems/dpl-1.10.8/bin/dpl:5:in `<top (required)>’

from /home/travis/.rvm/gems/ruby-2.4.5/bin/dpl:23:in `load’

from /home/travis/.rvm/gems/ruby-2.4.5/bin/dpl:23:in `<main>’

failed to deploy

GET 401 - Bad credentials // See: (Octokit::Unauthorized)

Are you sure your encrypted Github API key in .travis.yml is correct? Note that as per , Travis key pair is per-repository, so you need to somehow indicate to the travis encrypt command which key it is supposed to use (by either running the command in your project directory, or by passing -r).

hello :slight_smile:

today i setup a repo and got about the same error:

/Users/travis/.rvm/gems/ruby-2.4.3/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete’: GET 401 - Bad credentials // See: (Octokit::Unauthorized)

but also this lead to a failed build -
the upload itself worked - its done by the electron-builder - but this means the GH_TOKEN set in the repository environment variable is correct…

is this a sort of timing problem that two services try to login at the same time?! or something similar?

iam new to all of this - so i am sure my experiments do not make full sens at the current state… :wink:

my .travis.yml just contains

language: node_js
    - "12"

    - linux
    - osx
dist: xenial

cache: yarn

        - libusb-1.0-0
        - libusb-1.0-0-dev
        - libudev-dev

    - yarn release
    provider: releases
    api_key: GH_TOKEN
    # file: "FILE TO UPLOAD"
    skip_cleanup: true
    draft: true
    # on:
#     tags: true

first i had accidentally setup my repor with
after i found some mentionings that this error message can have to do with the move to i moved my experiment to the .com version…
but this did not fix it…

hope anyone can give me a hint why this error appears.

sunny greetings

Your API key is plain GH_TOKEN

which is most definitely incorrect.

If you have it set correctly, you’d want $GH_TOKEN in the file instead.

1 Like

yeah that makes sens!!!

Same issue, one more time

Please, fix this bug already. It’s really annoying that you have 0 steps bugs.

Your credentials are ostensibly encrypted So it’s a separate issue. As was brought up many times before, I encourage you to review documentation and try again. You may also use the settings page to set an env var, which you will use in .travis.yml (with a leading $, of course).

You might be frustrated that the things aren’t working as you expect, but there is no bug here.

Hi. I encourage you to actually read this topic. Token is encrypted and correct . GitHub Releases 1) Sometimes work,
2) Sometimes they work, but Travis job fails with this message
3) Sometimes job just fails randomly with no reason and release isn’t uploaded (same error message)

So there is a bug. It’s not fixed and didn’t got attention after more than month.

I don’t know, whether this is GitHub bug or Travis bug. I just report that there is a problem.

Original bug is with encrypted token. I don’t know why somebody marked this as solved, because random guy wrote here about another, unrelated problem with similar message.

So please, give appropriate response. Thanks in advance.

I can confirm you that your secret given in is wrong; it does not decrypt with the private key that we have on

You can try passing the -r flag ( or use the settings page to set the environment variable you would refer to in .travis.yml.

So you don’t care that you have serious security issue? So you, that anybody can upload GitHub release without API token. So my jobs uploaded release with wrong token.
Maybe I can change repo in .travis.yml to torvalds/linux and upload release with malicious code if token isn’t checked?

All my releases in GitHub are uploaded with Travis job and this token. So, please take apropriate action if this is security issue, when token isn’t checked.

Your releases are running from For example,

This explains why the credentials are wrong on and you get the releases uploaded correctly.

There is a confusion about .org and .com, for which we apologize, but there is no security issue here.

I suggest disabling builds on .org.