Conditional tasks

[Nachtfeuer]

Considering that the pipeline uploads/deploys something this usually will happen on concrete branches only. As an example in some projects using Git the branch master is used as main line. Each time a pull request gets merged there a successful build should provide artifacts somewhere. The next task snippet could be the way to do it:

- shell:
    script: echo "upload"
    when: "{{ env.BRANCH_NAME }}" == "master"

[Nachtfeuer]

Thinking a while about the topic I decided not to use Python and eval because I would like to avoid that somebody does someting else but a simple and readable condition. Also I don't want to write a complex parser for any condition because conditions should be simple and readable.

With this I came to following ideas about what should be supported:

• "{{ variables.branch_name }}" == "master"
• not "{{ variables.branch_name }}" == "master"
• "{{ variables.python_version }}" in [ "py27", "py35" ]
• "{{ variables.python_version }}" not in [ "py26", "py32" ]
• {{ variables.cpu_count }} == 1
• not {{ variables.cpu_count }} == 1
• {{ variables.cpu_count }} > 1
• {{ variables.cpu_count }} < 2
• {{ variables.cpu_count }} >= 1
• {{ variables.cpu_count }} <= 2

Of course model and env are supported too. However those formats can be validated via the schema also it's just a pre-validation because env and variable can be dynamically defined when the pipeline is running. Final validation and evaluation happens on each task only.

So here are some bad examples:

• "text1" == "text2" - we do not compare constants.
• "{{ variables.branch_name }}" in [ "master", 2, 3, 4 ] - the list is expected to have string values.
• "{{ variables.cpu_count }}" > 1 - comparison should be integers here.

I will not allow to use Jinja2 filters otherwise I would allow execution of code.
You still have the option to define a variable with a value based on any (complex) logic you like in your own Bash script, Python scripts or Docker container scripts.

[Nachtfeuer]

I decided not to use regex since the regex expressions got too complicated.
The new approach: AST. It seems (so far tested) that it does work on 2.x and 3.x.

The tokenizing is simply print(list(as.walk(ast.parse('2 == 3'))) which does return a list.
As an example typical entries are ast.Num, ast.Str and ast.Eq which make it quite easy
to check for a syntax.

[Nachtfeuer]

Most implemented (condition, validation and usage).
Looking forward to match wanted coverage (not all paths covered yet)
After that I have to extend the documentation for this feature (read the docs).