There's been a longstanding request to add control flow (if, for, while, etc) to the Evergreen configuration format. This is definitely something we need to address, but I am very wary about making the config format Turing complete. I'll let Google's awesome Kubernetes retrospective do the talking for me:
...configuration-management systems tend to invent a domain-specific configuration language that (eventually) becomes Turing complete, starting from the desire to perform computation on the data in the configuration (e.g., to adjust the amount of memory to give a server as a function of the number of shards in the service). The result is the kind of inscrutable "configuration is code" that people were trying to avoid by eliminating hard-coded parameters in the application's source code. It doesn't reduce operational complexity or make the configurations easier to debug or change; it just moves the computations from a real programming language to a domain-specific one, which typically has weaker development tools (e.g., debuggers, unit test frameworks, etc).
I think the solution that will ultimately require the least amount of debugging for both Evergreen developers and Evergreen users may be to offload task scripting to a true scripting language--perhaps we could just use the shell?
What if Evergreen commands were surfaced as executable commands that were brought into PATH? So instead of a complicated set of YAML commands, everything could be a shell command that hooks into Evergreen's provided features. Something like
could be written into a shell script as
which would allow us to easily do control flow around commands without writing and maintaining our own evergreen language. I'd imagine the "evg" binary would just be a mode for the agent binary that acted as a simple interface to send HTTP commands to the real agent process.
These commands wouldn't necessarily only be accessible through bash. Since they are just calls to a binary executable, they could be wrapped by practically any interpreted language.