"missing api_key" when deploying to GitHub releases

I’m trying to sort this out for a few hours now without success. I’m trying to deploy to GitHub releases but I’m getting following message on every build:

missing api_key
failed to deploy

Obviously my .travis.yml contains an API key which is even set up using travis setup releases --pro:

language: python
cache: pip

install:
- pip install -r requirements-test.txt

script:
- python -m unittest discover -s tests
- flake8 tspvisual

jobs:
  include:
  - name: Python 3.7 on Linux
    stage: test
    os: linux
    dist: bionic
    language: python
    python: '3.7'
  - name: Python 3.8 on Linux
    stage: test
    os: linux
    dist: bionic
    language: python
    python: '3.8'
  - name: Python 3.7 on Windows
    stage: test
    os: windows
    language: sh
    python: '3.7'
    before_install:
    - choco install python3 --version=3.7.4 --params "/InstallDir:C:\\Python"
    - export PATH="/c/Python:/c/Python/Scripts:$PATH"
    - python -m pip install --upgrade pip wheel
  - name: Python 3.8 on Windows
    stage: test
    os: windows
    language: sh
    python: '3.8'
    before_install:
    - choco install python3 --version=3.8 --params "/InstallDir:C:\\Python"
    - export PATH="/c/Python:/c/Python/Scripts:$PATH"
    - python -m pip install --upgrade pip wheel
  - name: PyInstaller on Linux
    stage: deploy
    if: tag IS present
    os: linux
    dist: bionic
    language: python
    python: '3.7'
    install:
    - pip install -f https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-18.04 -r requirements.txt
    - pip install -r requirements-build.txt
    script:
    - python -m build linux
    - mv dist/tspvisual-linux dist/tspvisual-${TRAVIS_TAG}-linux
    deploy:
      provider: releases
      api_key:
        secure: ...
      file: dist/tspvisual-${TRAVIS_TAG}-linux
      skip_cleanup: true
      draft: true
      overwrite: true
      on:
        repo: bcyran/tsp-visual
        all_branches: true
        tags: true
  - name: PyInstaller on Windows
    stage: deploy
    if: tag IS present
    os: windows
    language: sh
    python: '3.7'
    before_install:
    - choco install python3 --version=3.7.4 --params "/InstallDir:C:\\Python"
    - export PATH="/c/Python:/c/Python/Scripts:$PATH"
    - python -m pip install --upgrade pip wheel
    install:
    - pip install -r requirements.txt
    - pip install -r requirements-build.txt
    script:
    - python -m build windows
    - mv dist/tspvisual-windows.exe dist/tspvisual-${TRAVIS_TAG}-windows.exe
    deploy:
      provider: releases
      api_key:
        secure: ...
      file: dist/tspvisual-${TRAVIS_TAG}-windows.exe
      skip_cleanup: true
      draft: true
      overwrite: true
      on:
        repo: bcyran/tsp-visual
        all_branches: true
        tags: true

Thank you in advance for any help!

I don’t think I can link to the build itself as it’s a private repo. However I think this link to raw build log works without login.

I did use --pro option as it’s mentioned in my first post.

When reporting problems, please include relevant build URLs. Thanks.

Well, as I said before it’s private repo but here you go.

Are you sure this is the corresponding configuration? According to the records on our database, this job does not have any field named api_key in its configuration. In its place, all I see is token:

    deploy:
      provider: releases
      token: # ← WRONG KEY
        secure: WLH+ANJmyDGDESuw...
      file: dist/tspvisual-${TRAVIS_TAG}-linux
      skip_cleanup: true
      draft: true
      overwrite: true
      on:
        repo: bcyran/tsp-visual
        all_branches: true
        tags: true

Yes, I’m completely sure this the configuration for this build. This is what I see in “view config” tab. But I just noticed there’s also this suspicious message under “build config validation”:

jobs.include.deploy: key api_key is an alias for token, using token 
1 Like

Thanks for that extra information. We are looking into it.

For what it’s worth, I resolved this the other day by using edge: true (see https://github.com/owntracks/android/blob/master/.travis.yml):

deploy:
  provider: releases
  draft: true
  file: project/app/build/outputs/apk/release/app-release.apk
  edge: true
  on:
    tags: true

And then putting the github token in a secret env variable called GITHUB_TOKEN. Seems to work.

1 Like

Thank you, it worked!

However there’s still clearly some bug going on here.

https://travis-ci.org/lietu/better-dns/builds/613555528

Also got missing api_key -error, and fix for that was to add edge: true under deploy

For the past day few hours I’ve been caught with the missing api_key issue.

Using edge:true has fixed it for me, too.

As per GitHub pages deployment fails with "missing github_token", this is a bug in build config validation.

@BanzaiMan Where’s the source code for build config validation? I don’t see anything relevant in https://github.com/travis-ci/travis-web. There are relevant-looking functions in https://github.com/travis-ci/travis-web/blob/master/app/components/build-message.js but they aren’t used by anything.

Sorry about this issue everyone.

This is indeed an incompatibility of the feature Build Config Validation with the beta version v2 of our deployment tooling dpl which is not used by default, yet. Build Config Validation applies a formal schema to your build configuration that specifies things as required for dpl v2, but not dpl v1 even though this is still the standard version (if everything goes to plan this default will be switched in Jan). This is an oversight on our part in coordinating these two non-trivial releases.

We are working on ways to reduce these issues. In the meantime you can resolve this by opting into v2 using:

deploy:
- provider: [name]
  edge: true

We have just released dpl 1.10.14 which should be compatible with the aliases added in dpl v2. Please let us know if that fixes any of the issues.

We still also recommend opting in to dpl v2 which is going to become the new default version in January.

1 Like

I can see version 1.10.14 being installed, but it’s still not working. I added the edge: true fix and that looks to be the only fix.

thanks, adding edge: true worked for me too