Workaround for secure variables not substituted correctly

[Sebastian Hens]

Hello!

I'm trying to build a docker container and for that I defined a number of build args for it so data like a DB connection string is secured in the bitbucket repository per deployment (Test, Stage, Production). I noticed that the variables are not substituted.

Take this simplified version: 

docker build -t test:dev-1 -f ./Dockerfile --build-arg DATABASE_URL=$CI_DB_URL . 

CI_DB_URL is a secure value for my deployment Test. The container build will fail because it verfies the db connection and don't have a working value because it will get a "$CI_DB_URL" as a string instead of the substituted CI_DB_URL variable value.

I tested my own integration with a not secured value and this worked like expected. But I would prefer a secure value instead.

Does anyone know about this issue and how I can work around this? 

Cheers,

Sebastian

[Mark C]

Hi @Sebastian Hens,

Welcome to the community.

Would it be possible for you to confirm if you've declared the variable DATABASE_URL as ARG in your Dockerfile?

For example:

ARG DATABASE_URL

Regards,
Mark C

[Sebastian Hens]

Hi @Mark C 

thanks for your responds.

Yes I can confirm that. Something I also tried was writting the variable values into a .env file and copy that file with the other project files into the Dockerfile. After building the image I can confirm that in the .env file also just $CI_DB_URL is written and not the actual value.

echo "DATABASE_URL=$CI_DB_URL" >> .env

 The above code line works when I use a not secured variable in bitbucket for CI_DB_URL but not if it is a secure variable.

Regards,

Sebastian

[Mark C]

Hi @Sebastian Hens

I actually tried following this KB on essentially doing a similar example where I'm passing a secured variable to a Docker container.

Although Pipelines didn't print the secured variable value on my Pipelines build logs, I'm able to use it in a Docker container within Pipelines while cloning a repository.

This means the secured variable should work as expected.

Could you try to use different environment variable names and see how it goes?

Regards,
Mark C