multienv Fails if Env Vars Contain = (equals) Character

[austinsherron]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

Env vars added through multienv cannot contain the = character. This seems to be because multienv_step_runner.go splits on all = characters instead of just the first one, and then validates that the resulting slice has a length of exactly 2.

I'm not sure if there's a technical reason for this, but I kind of doubt it given that env vars with = characters are permitted via the env command. Quoting the values doesn't seem to help.

I think fixing this would be as simple as replacing the call to strings.Split(item, "=") in multienv_step_runner.go with strings.SplitN(item, "=", 2). I'd be happy to put up a PR for this.

Reproduction Steps

Try to add an env var through multienv in which the value contains =:

  a-workflow:
    plan:
      steps:
        - env:
            name: ENV_OKAY
            command: 'echo "this_env_var_contains_=_sign"'                   # doesn't fail
        - multienv: 'echo "ENV_FAILS=this_env_var_also_contain_=_sign"'      # fails
        - plan

Environment details

• Atlantis version: v.0.19.4

I checked the code, and the issue still exists in the latest version.

[arohter]

Yup, ran into this as well, in my case with values that are base64 encodes, with trailing = padding.

[jamengual]

multienv step was originally a json input and we asked to convert it to text, I guess that could be the reason why.

var=value makes total sense, I do not see the reason why not support it

[austinsherron]

@jamengual Would it be possible to get a quick look at #2354?

[vnhirenko]

Hi! Any workaround?

[adkafka]

A hacky workaround I came up with is to substitue the = for another special char (in my case *) in the script, then have another env section to substitute it back:

  workflows:
    my-workflow:
      plan:
        steps:
        # This script returns AWS_SESSION_TOKEN_ESCAPED with the = substituted out for *
        - multienv: my-script.sh
        - env:
            name: MY_ENV_VAR
            command: "echo $MY_ENV_VAR_ESCAPED | sed 's/*/=/g'"
        - init
        - plan

[acostaedg]

@austinsherron

Hello, I'm facing similar issue with Env vars added through multienv containing the comma (,) character, the error is the following:

{"level":"error","ts":"2022-12-09T14:15:30.592Z","caller":"events/instrumented_project_command_runner.go:42","msg":"Error running plan operation: Invalid environment variable definition:

My variables is something like this:

VARIABLE_NAME=hello, world, this, is, not, working

As the variable "VARIABLE_NAME" value contains comma (,) characters, looks like multienv cannot do the job and create the environment variables correctly.