Variable evaluation inside secret referencing

Need Help
1

Hi!

I have a use case where I need to duplicate configurations on two projects but one of them is referencing variables from the other.

Example:

---
DOPPLER_PROJECT: back
DOPPLER_ENVIRONMENT: dev
DOPPLER_CONFIG: dev_template

> doppler configs clone --config dev_template --name dev_branch_a

# Lets assume I have an SSH_KEY variable in dev_branch_a, 
# inherited from dev_template duplication.
# I need this value in a new duplicated configuration from another project:

---
DOPPLER_PROJECT: front
DOPPLER_ENVIRONMENT: dev
DOPPLER_CONFIG: dev_template
SSH_KEY: ${back.dev_template.SSH_KEY}

> doppler configs clone --config dev_template --name dev_branch_a

So $SSH_KEY from front project is pointing to a variable from a template instead of the dynamically created environment.

Is there a way to evaluate a variable inside a secret referencing mechanism ?
Something like ${back.dev_${GIT_BRANCH_SLUG}.SSH_KEY}

Regards,

2

Hi @mlvnds!

Welcome to the Doppler Community!

It’s not possible to nest secret references like that currently. I assume this is happening as part of some automation though since it’s dynamic? If that’s the case, your best bet would probably be to leave SSH_KEY empty in the root config for back and then set that secret to the appropriate value at the time of creation when you know what the branch name would be. So, something like this:

NEW_BRANCH_NAME=dev_branch_a
doppler configs clone --project back --config dev_template --name $NEW_BRANCH_NAME
doppler configs clone --project front --config dev_template --name $NEW_BRANCH_NAME
doppler secrets set --project front --config $NEW_BRANCH_NAME SSH_KEY="\${back.$NEW_BRANCH_NAME.SSH_KEY}"

Would something like that work for you?

Regards,
-Joel

3

Hi @watsonian !

Thanks for taking time to look at this.
You got the point, the purpose is only for dynamic environment created by our CI on review apps creation (gitlab-ci).

Your solution works but I was looking for something more convenient to use if many variables are defined (but my example was only about one SSH_KEY, so you solve the original problem).

As our developers could add more secrets on their environments, I have figured out a way to manage this use case without having to know and declare each nested secret references.

Definitely not the more convenient to read, but it does the job:

for secret in $(doppler secrets --project front --config dev_template --raw --json | jq -r --arg CUSTOM_ENV_NAME "$CI_COMMIT_REF_SLUG" 'to_entries | map(select(.value.raw | contains("back.dev_template."))) | map("\(.key)=\(.value.raw | gsub("dev_template"; $CUSTOM_ENV_NAME))") | .[]') ; do
    doppler secrets --project front --config dev_template set $secret
done

For every secret value with ${back.dev_template.XXX}, we replacing dev_template by a dynamic environment variable available on CI host during job execution.

Regards,