Hello there. While trying to rework one of our pipelines I got to the idea of potentially using the if block on some of the steps. However from reading the documentation I was unable to ascertain the exact semantics of the bloc, most notably when it comes to evaluation order and the time of evaluation of the condition.
The documentation does not indicate whether the specified conditions are evaluated:
- when the job is uploaded.
- whenever an event occurs that could put the job in a runnable state (e.g a depends_on step succeeds, etc).
- any other point in time.
This is most important because the evaluation context will determine whether something like a specific environment variable might be set yet (e.g via meta-data) or not, which seems to indicate that the evaluation happens at upload time.
The closest indication I have found until now is here on the forum in this post.
Would it be possible to get some clarifications on this, and to update the documentation accordingly? That would be really helpful for the next person to come along with the same ideas I was entertaining for a pipeline. 
Duco
Hey @dvanamst!
Conditionals are currently evaluated at job upload/creation time.
The loose intention is for that to probably change in the future, in order to allow more complex / dynamic behaviors.
… but it’s tricky to define how that should present visually. We don’t want a job to look like it will run until the last moment, if it actually won’t; we also don’t want a job to look like it won’t run until the last moment, if it actually will. (Think of a deploy step at the end of the pipeline, which is only intended run for commits to the primary branch – suggesting it won’t happen when it should is confusing, suggesting it might happen for some feature-branch commit is alarming, and marking it ‘maybe’ just seems uncommunicative.)
There are some corner cases where the current evaluation-time peeks through, but in general, the intention is that the currently-available set of variables should be pretty much constant throughout a build’s lifetime, such that it shouldn’t matter – in part, this is specifically to keep the door open for us to change it in the future.
I’ll see if we can find a way to document that detail without turning it into an unintended promise.