Qtox: Travis fails to deploy releases to github

Created on 26 Apr 2020  路  6Comments  路  Source: qTox/qTox

See https://travis-ci.org/github/qTox/qTox/jobs/678502211 which broke our v1.17.1 build, which had a fix attempted by https://github.com/qTox/qTox/pull/6111 but still fails in the same way, https://travis-ci.org/github/qTox/qTox/jobs/679613027
`` /home/travis/.rvm/gems/ruby-2.4.5/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:inon_complete': GET https://api.github.com/user: 401 - Bad credentials // See: https://developer.github.com/v3 (Octokit::Unauthorized)
````

C-bug M-packaging P-very-high

Most helpful comment

The changes in #6115 fix the deployment problems for qTox. A draft release is now available here: https://github.com/qTox/qTox/releases/tag/untagged-bdc792c1ce2f2070b501 but we need to update the version numbers and then push a new tag with the correct name.

I suspect adding the --org flag fixed the authentication problems. Thanks nurupo, I'd never guessed that could be an issue.

After fixing this problem there were some syntax changes in travis.yml which are also fixed now.

All 6 comments

@sudden6 when you updated the token in #6111, did you change GH_TOKEN in our travis settings? If not I think we should try deleting that in case it's still trying to use the old token.

Ping @nurupo in case you have better ideas regarding this.

@anthonybilinski no I did not change GH_TOKEN, I think it has nothing to do with our problem or is even unused.

Test locally if the token works (keep user):

curl -v -H "Authorization: token TOKEN" https://api.github.com/user

When you call travis encrypt to generate the secure token, try passing --org flag to it. Just a shot in the dark here.

You could also try fixing errors and warnings related to the deploy section.

Maybe try setting the token in Travis-CI's web UI instead (don't encrypt it with travis encrypt) and then set api_key (without secure) to that env variable.

Alternatively, you could setup CIRP to create a --tag_release, either in qTox-nightly-releases or qTox repo, either draft or non-draft.

Just note that the way CIRP handles build restarts with tag releases - as long as the release exists, CIRP won't attempt to re-create it when someone restarts the build. However, if you delete the release (you can either keep or delete tag, they are separate entities from releases), and someone restarts the build that pushed the tag, even days/weeks/months after it first ran, CIRP will create the release, and if needed the tag too. It's because it has no idea if it's the first time this build is running (there is no way to find out that in Travis-CI API), so it sees that there is no release and assumes that it's the first time.

A draft release into qTox-nightly-releases might be the safest option -- uses qTox-nightly-releases's access token and you don't have to care about deleting releases and restarting builds for them in the future as it's a draft release -- no users would see them even if they get re-created and draft releases don't create tags, so there would be no visible change on qTox-nightly-releases. You would just have to manually re-upload the artifacts from the draft qTox-nightly-releases release to the qTox release.

The changes in #6115 fix the deployment problems for qTox. A draft release is now available here: https://github.com/qTox/qTox/releases/tag/untagged-bdc792c1ce2f2070b501 but we need to update the version numbers and then push a new tag with the correct name.

I suspect adding the --org flag fixed the authentication problems. Thanks nurupo, I'd never guessed that could be an issue.

After fixing this problem there were some syntax changes in travis.yml which are also fixed now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dxerw picture dxerw  路  5Comments

andriusign picture andriusign  路  4Comments

dubslow picture dubslow  路  6Comments

david-camden picture david-camden  路  7Comments

anthonybilinski picture anthonybilinski  路  3Comments