Bitbucket-pipelines.yml variable name resolved by export

w.jasaragic July 8, 2021

During the deployment of a project in acceptance a strange thing occurs.

We have a step in our bitbucket-pipelines.yml that builds a Docker image and pushes it to our registry.

Screenshot-20210708223029-957x432.pngScreenshot-20210708223147-926x562.png

pipeline-variable-magic.png

 

```docker run --cpus=1 --memory=1G --restart=always --name $FQIN_IMAGE_NAME --build-args...```

 

Example given.

If DOCKER_RUNNING_NAME="acceptance-duck"

And the Repository variable $PROD_DBNAME= duck.

The DOCKER_RUNNING_NAME becomes acceptance-$PROD_DBNAME.

 

A variable name that is set on repository level appears in the pipeline by the value it contains.

If we change the value of the variable to something else, the variablename dissappears.

 

How is this even possible? Do we miss a quote or something else?

1 answer

1 accepted

0 votes
Answer accepted
Caroline R
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 15, 2021

Hi, @w.jasaragic!

Before we start, I'd like to confirm that I've understood properly what is happening on your side. Feel free to correct me in case I have misunderstood something here.

Apparently, you have set 2 types of variables:

  • One on your bitbucket-pipelines.yml: export DOCKER_RUNNING_NAME="acceptance-duck"

  • Another one on your Repository variables: $PROD_DBNAME= duck.

Then, when running the pipelines, the DOCKER_RUNNING_NAME becomes "acceptance-$PROD_DBNAME", like here:

export DOCKER_RUNNING_NAME="acceptance-duck"

+ export DOCKER_RUNNING_NAME="acceptance-$PROD_DBNAME"
echo $DOCKER_RUNNING_NAME

+ echo $DOCKER_RUNNING_NAME
acceptance-$PROD_DBNAME

Is that correct? If that’s the case, this is the expected behavior, as the system will read all the content and replace any repository variables you have set.

Please let me know if something is being misinterpreted here and don't hesitate to ask for any further information if needed.

Kind regards,
Caroline

w.jasaragic July 16, 2021

Hi @Caroline R

Should that be the expected behavior? 

A variable value should be resolved by variable name, not the other way around.

 

Scenario

Repository variable:

  • PROD_DBNAME = duck

Bitbucket-Pipelines.yml: Actual

export DOCKER_RUNNING_NAME="acceptance-duck"
+ export DOCKER_RUNNING_NAME="acceptance-$PROD_DBNAME"
echo $DOCKER_RUNNING_NAME
+ echo $DOCKER_RUNNING_NAME
acceptance-duck

Bitbucket-Pipelines.yml: Expected

export DOCKER_RUNNING_NAME="acceptance-duck"
+ export DOCKER_RUNNING_NAME="acceptance-duck"
echo $DOCKER_RUNNING_NAME
+ echo $DOCKER_RUNNING_NAME
acceptance-duck

I expect that the system will read all the content and replace any repository variables that is set. But I do not expect that it will resolve the variable name by value.

 

If I change PROD_DBNAME to duckk, the output will be:

export DOCKER_RUNNING_NAME="acceptance-duck"
+ export DOCKER_RUNNING_NAME="acceptance-duck"
echo $DOCKER_RUNNING_NAME
+ echo $DOCKER_RUNNING_NAME
acceptance-duck

 

How come the variable name is resolved by value as $PROD_DBNAME is not used at all in this step?

 

Thankyou in advance.

Caroline R
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 20, 2021

Hi, @w.jasaragic.

Indeed, if we have a secured variable named "PROD_DBNAME' with the value "duck", Pipelines will replace any existence of the word "duck" in the logs with $PROD_DBNAME, even if we don't call the variable PROD_DBNAME. If its value appears in the logs, it will be replaced with the variable name.

This is mentioned in our documentation:

Pipelines masks all occurrences of a secure variable's value in your log files, regardless of how that output was generated.

"regardless of how that output was generated" means that Bitbucket doesn't look at how the value of the secured variable appeared in the logs. So, this behavior is by design, Bitbucket will replace every instance of the value of a secured environment variable with the name of the variable. 

I hope this clarifies the situation, but please let me know if you have any questions. 

Kind regards,
Caroline

w.jasaragic July 22, 2021

Hi @Caroline R

Thank you for your quick response. That explains it.

The issue has now been resolved :)

Like Caroline R likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events