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

20.build-args encrypted_args_file not working #34

Open
aetheon opened this issue Mar 3, 2017 · 10 comments
Open

20.build-args encrypted_args_file not working #34

aetheon opened this issue Mar 3, 2017 · 10 comments

Comments

@aetheon
Copy link

aetheon commented Mar 3, 2017

The example is not working as on the build phase the variable has no value. not sure if is the docker version.

@rheinwein
Copy link
Contributor

rheinwein commented Mar 7, 2017

@aetheon Are you running this locally with the Jet CLI, or on Codeship? If you are using the CLI, could you report the version, as well as the Docker version you use?

If the failure is related to all of build args, we need to dig a bit deeper. But if it's just related to the encrypted variable -- that's because you don't have access to Codeship's key. I'll remove that example from the repo, sorry about that.

@aetheon
Copy link
Author

aetheon commented Mar 15, 2017

Hey @rheinwein, was running locally, didn't try on codeship.

Docker version 1.13.1, build 092cba3
Jet version 1.14.1

As you can see on the screenshots the args are not being passed correctly (e.g. UNENCRYPTED should be 'foo'). From my reading I think this is not possible with the latest docker. There's a workaround that we are using, let me know if you are interested.

screen shot 2017-03-15 at 14 20 27

screen shot 2017-03-15 at 14 21 34

@rheinwein
Copy link
Contributor

Hey @aetheon You're right -- encrypted build args are not a Docker feature, they're an additional feature from Codeship specifically designed for CI/CD.

Looks like you're using an older version of the CLI that doesn't have full support for build arguments. You can see release notes on our docs page, and grab the new CLI version, which should fix your issue.

We'll remove (parts of) this example from the repo, since it won't work for anyone outside of the Codeship organization -- you don't have access to our key to unencrypt the variable.

@tylerbakke
Copy link

tylerbakke commented Aug 23, 2017

Hi @rheinwein, I am also having a issue with encrypted_args_file but it doesn't work when running it on Codeship with our .aes key.
codeship-services.yml:
screen shot 2017-08-22 at 5 15 11 pm
decrypted deploy/codeship.env(values removed):
screen shot 2017-08-22 at 5 16 15 pm

@mlocher
Copy link
Contributor

mlocher commented Aug 23, 2017

@tylerbakke could you open a ticket on https://helpdesk.codeship.com with the error message you get and (if possible) a link to the builds on Codeship?

The config looks good, and if you can decrypt the file locally it should work with the automated builds as well, as long as the key you use locally is the same as the one specified on the projects General settings page.

@domdorn
Copy link

domdorn commented Apr 3, 2018

Is there any update on this?
I'm trying to configure encrypted build-time args on my codeship pro build (for my paying customer) and the feature is not working!

I verified that I used the latest version of the JET CLI.
image

In general, it would be good to update all the samples to include an aes key, so they can run by themselves (e.g. like done in ./11.encrypted-aes)

@thomastoye
Copy link

@rheinwein Any update to this? This is still broken.

...
(service: app) (step: /app/test-build-arg.sh) UNENCRYPTED has been set to foo
CI has been set to false
Encrypted build args are not working. ENCRYPTED should not be default.
(step: /app/test-build-arg.sh) error ✗
(step: /app/test-build-arg.sh) container exited with a 1 code

(After creating a new AES key file, re-encrypting the build args and running jet steps)

Jet version 2.10.0, docker version:

Client:
 Version:           18.09.0
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        4d60db4
 Built:             Wed Nov  7 00:49:01 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.0
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       4d60db4
  Built:            Wed Nov  7 00:16:44 2018
  OS/Arch:          linux/amd64
  Experimental:     false

@rheinwein
Copy link
Contributor

@thomastoye are you working from a fork, and have you set that fork up as a CodeShip project? If no, the testing script won't pass for you, since the encrypted build args are using CodeShip's key, which you don't have access to.

However, you do seem to have uncovered a bug with encrypted build args passed directly into the codeship-services.yml file (like this and this). The eng team will follow up with that after the holiday.

Passing in a file of encrypted build args works as expected. If you want the tests in the 20.build-args dir of your fork to pass, you can append the build_arg file with ENCRYPTED=some_value and using the AES key provided to your project on CodeShip, reencrypt that file with jet encrypt build_args build_args.encrypted. Running jet steps in that directory (with your AES key present) will show you the encrypted build args in action.

@kiwimato
Copy link

kiwimato commented Dec 6, 2019

Any update on this or perhaps a workaround?
I have the same issue and the set bash command shows variables on build time.
EDIT: Forgot to mention, for me it's about app.codeship.com, so not the local utility.

@kiwimato
Copy link

kiwimato commented Dec 9, 2019

I finally got it working, but I had to add all the variables present in build_args.encrypted to the Dockerfile as well. Unfortunately I did not find anything in your documentation to specify this.
Example of what I added to my Dockerfile:

ARG AWS_ACCESS_KEY_ID
ARG AWS_SECRET_ACCESS_KEY
ARG AWS_REGION

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

7 participants