Dpl: deploy.api_key not working while using build config imports

[crazy-max]

Hi @svenfuchs,

Ok so I have tried to use a secret on deploy.api_key using build config imports but nothing seems to work right now.

Declare api_key at root

I have tried to declare deploy.token.secure on my .travis.yml while importing .travis/config/deploy.yml but it fails with missing api_key.

Looking at the build config, the token is overwritten or not taken into account from my .travis.yml.

Use GITHUB_TOKEN env var

Next I have seen the dpl v2 API allows to use env vars to declare options but it fails too with missing api_key. Here is my .travis.yml, the .travis/configs/deploy.yml and the final build config.

Thanks for your time!

[crazy-max]

I have also tried to use travis env set GITHUB_TOKEN ... but it fails too.

[svenfuchs]

thanks for the report, @crazy-max!

for context, there's been some switching around of aliases, and introducing new aliases going on in dpl v2, partly requested by the respective providers. so right now some of the docs for v1 do not apply to v2 any more and the other way around. on top of that, the feature "Build Config Validation" also now applies the same aliases as v2 expects, so v1 and "Build Config Validation" unfortunately do not mix well for some providers (we're looking into that).

releases on dpl v2 definitely should accept token, but api_key is an alias for that and also should be accepted https://github.com/travis-ci/dpl/blob/master/lib/dpl/providers/releases.rb#L24 and https://github.com/travis-ci/travis-yml/blob/master/lib/travis/yml/schema/def/deploy/releases.rb#L20 (since you have "Build Config Validation" enabled).

i think the issue is that the way you have declared

deploy:
  api_key:
    secure: [...]

this does nothing :)

api_key (or now the new option name token, both should work) needs to be declared on what you have in your deploy.yml ... which btw does not use v2 in this case.

i believe this should work (skip_cleanup is now default):

deploy:
  provider: releases
  token: 
    secure: [...] # be sure to encrypt this with the key from portapps/portapps
  file_glob: true
  file: bin/release/*
  draft: true
  on:
    tags: false
  edge: true # use v2

if you want to use travis env set i believe for releases it needs to be RELEASES_TOKEN.

let me know if any of this helps.

[svenfuchs]

oh, if you have travis env set GITHUB_TOKEN ... already set then you could also do:

deploy:
  provider: releases
  token:  $GITHUB_TOKEN

... but this would mean you have to set the secret on all repos that use deploy.yml. if you want to reduce this work you could share the secret in deploy.yml (which however means every repo owned by portapps has access to this, and with it, all developers having push access. not sure if that's acceptable in your case.

[crazy-max]

@svenfuchs

be sure to encrypt this with the key from portapps/portapps

Ahhhhh game changer if I can use an unique deploy token for my whole org!!
But I also thought I would share this configuration with users outside this organization if they want to use Portapps on their personal repository. So I'll try RELEASES_TOKEN env var.

I will keep you informed and thank you for your efficiency!

[crazy-max]

@svenfuchs

oh, if you have travis env set GITHUB_TOKEN ... already set then you could also do:

deploy:
  provider: releases
  token:  $GITHUB_TOKEN

Hummmm I thought env vars could susbtitute options.

[crazy-max]

@svenfuchs Using travis env set RELEASES_TOKEN ... is not working unfortunately. Will try your other solution.

[svenfuchs]

Hummmm I thought env vars could susbtitute options.

they're two different solutions. if you use token: $GITHUB_TOKEN you can choose whatever var name you want. while dpl v2 picks up certain env vars automatically based on their name.

are you sure you are using dpl v2? these tests all pass: https://github.com/travis-ci/dpl/blob/master/spec/dpl/providers/releases_spec.rb#L146-L168

https://travis-ci.com/portapps/handbrake-portable/jobs/255801936/config does not have the edge: true opt-in that makes it use v2. i'd definitely recommend using v2

[crazy-max]

does not have the edge: true

@svenfuchs Jeeeez that must be it!

[crazy-max]

@svenfuchs Yeah that was it! Sorry to have wasted your time :disappointed:

[svenfuchs]

@crazy-max no worries at all, glad you figured it out. thanks again for the report!