what is the reason that the docker-sdk generator uses json_encode() to encode the project secrets? I have a secret like

MY_SECRET: "abc/def"

and this ends up like

MY_SECRET: "abc\/def"

in the env file being generated because of this, which of course is a different value

@high-pencil-62400?

Hi Rene, Where do you set MY_SECRET value for docker/sdk to catch it up?

@high-pencil-62400 in the deploy.yml under

project:secrets

1. It is abuse of wrong-named internal intermediate variable. And anyway according the code:

$projectData['secrets'] = buildSecrets($deploymentDir);

It will be overridden with auto-generated secrets. How does it work for you? 2. Secrets MUST NOT be defined in deploy.yml. We have a feature in backlog that will allow to declare secrets and pass it from env. 3. To solve your particular issue use the following:

image:
  tag: spryker/php:7.3
  environment:
    COMPOSER_HOME: blah blah

That will embed env variable into image. And again this cannot be used for secrets.

hey @high-pencil-62400 I am not talking about

$projectData['secrets']

, I am talking about

$projectData['project']['secrets']

(the YAML definition is

project:secrets:

, not top-level

secrets:

), they are being parsed by `generator/src/templates/env/common.env.twig`:

{% for secretKey, secretValue in project['secrets'] %}

it is definitely working for me, the values I set there are being added to the generated .env files. So this is a "wrong-named internal intermediate variable", yes? I should not use it? How should I do it then? 😄 Currently not possible, because of your second point? And regarding

image:environment:

thanks! This sounds definitely like a better solution. But why do you suggest it should also not be used for secrets? Because it is not secret? 😄

Thanks for finding this caveat. It should not work that way.

oh okay 😄

Secrets must be secured. And deploy.yml should be committed into a repo. And that is not so secure. Secrets must be passed only in runtime. And we have only support for internal secrets only for now.

thank you @high-pencil-62400!!! 🙂 Looking forward to the new feature with being able to store secrets correctly, until now I will use a workaround 🙂

I'm already looking forward to this. I think it would be fine for many (local / development) cases to have a

.env

(if existing and maybe with environment naming scheme like .env.stage .env.prod) automatically been included while docker/sdk boot. the variables from this file should end up in the different

{service}_{store}.env

files in

/docker/deployment/default/env/

@plain-barista-64036 Please, register this as an idea. Thanks.

Little bit late, but here it is: https://spryker.ideas.aha.io/ideas/CUSTIDEAS-I-140