dpl: Unable to figure out how to encode the deploy key from the docs

Hi @svenfuchs, me again; thanks so much for the help with the new deploy key feature. Here’s another issue I ran into.

It appears the intent of the feature is to put the deploy key directly in the .travis.yml. Presumably encrypted using travis encrypt. The readme says

  --deploy_key KEY               A base64-encoded, private deploy key with write access to the repository (type:
                                 string, note: RSA keys are too long to fit into a Travis CI secure variable, but
                                 ECDSA-521 fits, see:
                                 https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys)

and https://github.com/travis-ci/dpl/pull/695 suggested

    travis encrypt DEPLOY_KEY="$(cat deploy_key|base64)"
    dpl --provider=pages --deploy-key="$DEPLOY_KEY" --local-dir=build

although that wasn’t ported over. But when I follow these instructions, I end up with the following in my logs:

Setting environment variables from .travis.yml

$ export DEPLOY_KEY=[secure]

We were unable to parse one of your secure environment variables.

Please make sure to escape special characters such as ' ' (white space) and $ (dollar symbol) with \ (backslash) .

For example, thi$isanexample would be typed as thi\$isanexample. See https://docs.travis-ci.com/user/encryption-keys.

(see live at https://travis-ci.org/w3c/payment-method-manifest/builds/575963835) and then of course deployment fails to authenticate.

Any ideas?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (14 by maintainers)

Most upvoted comments

@domenic thanks for the confirmation! 🎉

i don’t see much room for improvement, except maybe:

skip_cleanup is true by default starting in v2, so you can remove that option
the command line parser we now use under the hood does not care about dashes - vs underscores _ any more (except negation via no- needs a dash to work on all supported Ruby versions, sadly), so you can unify your style. i’d recommend underscores as that’s what the readme will document, too, but it’s really up to you.
i personally like to order keys according to the general flow, so i’d move before_deploy before deploy (heh), and move notifications to the end (and maybe branches below language, so the scripts sit closer together), but you probably have a reason ordering them the way you have them

but then again, this is all style.

it’s great to know this works well for your usecase!

svenfuchs on Aug 26, 2019

@jyasskin fair point. it already moves the decrypted key out of the working dir to ~/.dpl where it has to sit in order for several commands to succeed (among them testing the key with ssh -i [...] -T git@github.com. if any of these commands (including moving the file) fail then the deploy process gets aborted.

in addition to that i have now added a git pre-commit hook in https://github.com/travis-ci/dpl/commit/6be070d4cb6b99e6169adda556af640017d7fdb0. it gets installed right before we commit.

this build has rejected a fake left over key https://travis-ci.org/svenfuchs/test/builds/576447948#L188 from https://github.com/svenfuchs/test/blob/dpl_test/.travis.yml#L8

svenfuchs on Aug 25, 2019

I did this a long time ago, but I think I avoided encrypt-file because it leads to an unencrypted file in the build tree during the build, at the same time that the deploy step is uploading part of the build tree to a public HTTP server, and I didn’t want any chance that a user error could upload the unencrypted secret key.

If that worry doesn’t make sense anymore, or there’s something else defending against it, I have no objections to the change.

jyasskin on Aug 25, 2019