refactor: env_name.txt to always have the used env name (IN-1895)

[theProf]

Remove skip_create_env, always store the environment name to be used in env_name.txt , in the creation step check value of env_name.txt against << parameters.env-name >> , creating an env if different. Should always be able to trust the value in env_name.txt to be an env (not "null").

[linear]

IN-1895 Update env_name.txt checks for a value of `null` and not just file existence

[theProf]

• refactor: env_name.txt to always have the used env name #317
• refactor: env_name.txt to always have the used env name (IN-1895) #316 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[vf-service-account]

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/voiceflow/common?version=dev:6f4e9f7de7cb900aec766b7930c0845d320886e5

[vf-service-account]

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/voiceflow/common?version=dev:1f1efeb9b8833964abb6232009718157f2124bd3

[vf-service-account]

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/voiceflow/common?version=dev:b463960b8f7ee3b9d4e4e301062490d1ed624a7f

[junydania]

should we use [[ ]] for safer shell scripting ?

[theProf]

right, i've been writing my scripts to be posix compliant for alpine shells, but we bash it up in CircleCI

[junydania]

Also, should we maybe just cat the env-name-path once. This block does reduce the lines of code. My suggestion here, more lines of code however we don't have to call cat twice

      if [[ -f << parameters.env-name-path >> ]]; then
        file_content=$(cat << parameters.env-name-path >>)
        if [[ -n "$file_content" && "$file_content" != "null" ]]; then
          echo "Using env_name from file << parameters.env-name-path >> in the suspend action"
          env_name="$file_content"
        else
          env_name="<< parameters.env-name >>"
        fi
      else
        env_name="<< parameters.env-name >>"
      fi
      echo "Using env: ${env_name}"

[theProf]

yup, we can do it in one, though instead of nesting i'd rather:

file_content=$(test -f << parameters.env-name-path >> && cat << parameters.env-name-path >>)

[junydania]

This new logic cleanly simplifies things, however I am concerned that it drops most of the explicit signals we have encountered with several edge cases on circleCI

In the force case, it does not modify env_name.txt after its initial assignment. It doesn't ensure environment creation is forced. Also this comparism [[ $(cat env_name.txt) != "<< parameters.env-name >>" ]] could lead to ambiguity in edge cases if << parameters.env-name >> is not set correctly or the file’s content is modified

We lose alot of the explict signals. I think in the early days of development, we noticed some weird behavior, hence, reason for the explicit signals. If we can have that with this simplified code, could help us overcome some edge case behavior in circleCI

[theProf]

so my thoughts around this are:

1. the explicit signaling does not add clarity as to why or what edge cases it is for
2. from the above, when/how is env_name.txt not properly set (As it is only set in the above step)

Here is a chart of logical outcomes from the previous logic:

| pool-type | force | skip_create_env | env_name.txt |
| --------- | ----- | --------------- | ------------ |
| value     | false | skip            | e2e-7asdfa   |
| value     | false | create          | null         |
| value     | true  | create          | null         |
| value     | true  | create          | null         |
| value     | true  | create          | null         |
| value     | true  | create          | null         |
| value     | true  | create          | null         |
| value     | true  | create          | null         |
| -         | false | create          | null         |
| -         | false | create          | null         |
| -         | false | create          | null         |
| -         | false | create          | null         |
| -         | false | create          | null         |
| -         | false | create          | null         |
| -         | true  | create          | null         |
| -         | true  | create          | null         |
| -         | true  | create          | null         |
| -         | true  | create          | null         |
| -         | true  | create          | null         |
| -         | true  | create          | null         |

| found free | skip_create_env | env_name.txt |
| ---------- | --------------- | ------------ |
| true       | skip            | e2e-7asdfa   |
| false      | create          | null         |

I took this and simplified it to

the only time env_name.txt has a value that's not << parameters.env-name >> is when we were setting skip_create_env to "skip"