Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only one api_key? #323

Closed
ndw opened this issue Aug 31, 2015 · 7 comments
Closed

Only one api_key? #323

ndw opened this issue Aug 31, 2015 · 7 comments
Labels

Comments

@ndw
Copy link

ndw commented Aug 31, 2015

I've successfully used 'travis setup releases' to build a deploy stanza in several projects. But I'm confused by an apparent limitation.

The project I'm working on now is a fork of official/repo. So I setup a deploy stanza in my fork so that ndw/repo can publish releases. So far so good. Then I set it up in official/repo and I merge the two .travis.yml files so that they can be shared. I expected the "-secure: ..." list of keys trick that works for global environment variables to also work for multiple deploy keys.

But it doesn't seem to. Either one or the other repository (or both) raises an error and the build fails.

Am I doing something stupid, or is this a known limitation?

Assuming the latter, what are the recommended workarounds?

@BanzaiMan
Copy link
Contributor

Our encryption uses the encryption key which is tied to each repository.

You cannot use this key in any other repository. This is not shared between a repository and their forks, either. Otherwise, any malicious user can fork your repository and reveal the secret from the source repository. (http://docs.travis-ci.com/user/pull-requests/#Security-Restrictions-when-testing-Pull-Requests)

PRs should not have any encrypted data, because it cannot be used. If you encrypt ENV1=VAR1 in the PR and are satisfied with the change, you have to have the corresponding change done in the base branch independently.

@ndw
Copy link
Author

ndw commented Sep 1, 2015

I'm not concerned specifically about pull requests, although I'm using them.

The .travis.yml file contains encrypted environment variables that I can share across forked repositories. Only the ones that are encrypted with the key for my repo actually get decrypted when the build runs.

I was expecting something similar for the encrypted keys associated with deployment. I want Travis to be able to deploy a release to ndw/repo when I tag commits there. At the same time, when changes are merged back into official/repo, if a commit is tagged there, I want Travis to be able to deploy a release to official/repo.

@BanzaiMan
Copy link
Contributor

Encrypted secrets in deployment providers work the same way.

I suggest setting these secrets on the Settings page on each repository in question, so that the encrypted secrets do not have to be merged back and forth in .travis.yml.

@ndw
Copy link
Author

ndw commented Sep 1, 2015

The Travis-CI settings page has a section for environment variables, but I didn't get the impression that the api_key was an environment variable. Or is it possible to set the value of the key to an environment variable?

Can you point me to an example where an encrypted secret for a deployment provider is setup this way?

@BanzaiMan
Copy link
Contributor

Now that you mention, I realize that it might be true that some deployment providers may not respect environment variables as option values, in which case my previous statement is incorrect.

@BanzaiMan
Copy link
Contributor

See #280.

@stale
Copy link

stale bot commented Apr 12, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label Apr 12, 2018
@stale stale bot closed this as completed Apr 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants