Reuse environment variable in another variable


#1

I’m trying to create an environment variable DOCKER_IMAGE that includes the {execution.start_date} with a custom formatting in it.

DOCKER_IMAGE = myapp-$(date --date='${execution.start_date}' +%Y%m%d-%H%M%S), which should produce the value myapp-20170726-225503.

In my SSH script I then try to build the docker image:

sudo docker build -t ${DOCKER_IMAGE} .

But it complains:

sudo docker build -t $DOCKER_IMAGE . - Failed
FAILED date: invalid date ‘${execution.start_date}’

This tells me that my $DOCKER_IMAGE variable did not expand the ${execution.start_date} variable.

I did also try exporting the variable inside the SSH script, but it seems each line of the SSH script is executed in a way that the exported environment variable is not seen on the subsequent lines.

How can I go about embedding info from execution in a variable so I can reuse it in multiple actions?


#2

@anjdreas, unfortunately for now it’s not possible to use buddy params in the environment variables.

If you mean the date you’d get it this way:
${DateUtils.fromString(${execution.start_date}).toString(‘YYYMMdd-hhmmss’)}

Make sure to set this variable in the first line of the SSH action.


#3

I did also try exporting the variable inside the SSH script, but it seems each line of the SSH script is executed in a way that the exported environment variable is not seen on the subsequent lines.

My experimentation tells me that setting a variable early in the SSH action DOCKER_IMAGE = <value> does not allow lines below it to read the value of the variable, neither when using export DOCKER_IMAGE = <value>. It seems each line is run in an isolated shell.

Example code:

MY_VAR="foo"
echo "My value: $MY_VAR"

Prints:

My value: 

Do I misunderstand something?


#4

Hey Andreas. You’re right: this is how the SSH action works for now.

You’d have to use it the following way to make it work:
MY_VAR="foo" && echo "My value: $MY_VAR"


#5

That approach kind of defeats the point though, as I find it just as cumbersome to have the entire script be a single line.

If you could forward two feature requests to the team for me:

  1. Expand Buddy’s variables in my project/pipeline variables
  2. Run SSH action as a bash script, so things like shell variables and for-loops can be used

#6

Thanks, I’ll forward it to the team and keep you posted.


#7

By the way, I just discovered a workaround. I can use VTL (the template language used to inject variables) to store variables like this: #set ($myvar = "myvalue") and reference it like any normal variable later on in the script. That solves my problem, and this should probably go into the docs.

Also in the docs, the last section on non-buddy variables is plain wrong if I understand it correctly. Their exact example did not work for me in an SSH Action at least.


#8

Andreas,
The workaround works okay (y). Regarding the non-buddy variables, the example works okay:
let’s assume you have a HOME=test variable in your pipeline + you ssh to a server with HOME=/root in the system. If you refer to $HOME, the value will be test, and if you enter #[[$HOME}]]# the value will be root.


#9

Sure, but the example was misleading (to me). I read it as I could write this in my SSH action:

filename="myfile.ext"
echo ${filename##*.}

but as discussed, this does not work due to how SSH action performs each line in isolation.
I understand that if I had a buddy variable filename then this would work, but the title of the section is Using non-Buddy variables in builds and SSH scripts and the way I read it, I thought it meant shell variables.