How do I reference an env_var_name param from inside code wrapped inside include()?

Build Environment
1

I have a command with an env_var_name parameter. The command has a step that uses a command that uses include() to wrap a script. I’m unsure of the syntax I am supposed to use in order to reference the value of that parameter from within the script since the include() wrapper seems to escape my double arrows <<

commands:
  my_command:
    parameters:
      foo:
        description: Blah
        type: env_var_name
        default: MY_SECRET_THING
    steps:
      - run:
          name: Attempt 1
          environment:
            FOO: << parameters.foo >>
          command: echo "${FOO}" # prints string literal "MY_SECRET_THING"
      - run:
          name: Attempt 2
          command: echo "${<< parameters.foo >>}" # properly prints redacted contents
      - run:
          name: Attempt 3
          command: <<include(scripts/my_script.sh)>> # improperly escapes <<

Contents of scripts/my_script.sh:

echo "${<< parameters.foo >>}"
2

Hi @omgitsbillryan,

I’m not sure if this approach would suit you, but it does work:

  - run:
      name: Attempt 3
      environment:
        FOO: << parameters.foo >>
      command: <<include(scripts/my_script.sh)>>

 
And the content of scripts/my_script.sh would need to be:

echo "${!FOO}"
2 Likes
3

This is a decent work-around that should work in most cases. I have lengthy scripts I want to outsource to the scripts/ directory so I can shellcheck them, yet include them and evaluate parameters.

2 Likes
4

This is how I typically do it as well :point_up:
I sometimes use an undescore prefix on the env var like _FOO: << parameters.foo >>

I think since the inline script gets rendered into the yaml as well, it will also “work” to directly use the mustache templating (i.e., reference << parameters.foo >>) in the script, except that it won’t be runnable / testable in there, and probably won’t pass shellcheck as @bjd2385 mentions.

I have lengthy scripts I want to outsource to the scripts/ directory so I can shellcheck them, yet include them and evaluate parameters.

Yeah, same thought process / reasoning for me.
I recently had a case where it was a super short script, and there, passing in the vars seemed too messy and like overkill, so ended up just inlining it in that case.

1 Like
5

I ended up prefixing with SH_*, so I took a similar approach.

6

Follow up: I found I had to set

VAR="$(eval echo "$SH_VAR")"

in the case that I was referencing env vars referencing context vars.

1 Like
7

Heads up here. This can cause issues if you pass something in that isn’t an environment variable for instance. This will work just fine for you personally but we have run into issues trying to accommodate users who want strings and/or environment variables. If you pass in a literal string containing an equal sign for instance, it will break as it will interpret it as literal arithmetic.

If possible, you may want to use a tool like envsubst. I am currently putting a PR to the CLI to see what people thing about adding this tool directly to the build environment.

Example: echo 'welcome $HOME ${USER:=a8m}' | envsubst

On debian the original binary can be installed as gettext-base
sudo apt-get install gettext-base

1 Like