In the documentation for conditions in Azure DevOps pipelines the following example is given:
and(always(), eq(variables['Build.Reason'], 'Schedule'))
Why would you include the "and(always()" part? To my understanding it is semantically equivalent to just:
eq(variables['Build.Reason'], 'Schedule')
Or am I missing something?
This example is titled as "Run if the build is scheduled, even if failing, even if canceled".
So, this condition:
eq(variables['Build.Reason'], 'Schedule')
is for "Run if the build is scheduled" part.
And this condition:
always()
is for "even if failing, even if canceled" part.
Those two are composed with and(...). That's it.
You're right Kristoffer, the two conditions are behaviourally equivalent.
I would offer one reason to use the long version though:
and(always(), eq(variables['Build.Reason'], 'Schedule'))
When writing task conditions, it is easy to forget that succeeded() is the default, and if you don't include it then your task will run even if the job is failing or cancelled.
So I think it would be a good practice to write all conditions with succeeded() (or always() or cancelled() or whatever) included in the expression; then if you see a condition without it, like this:
eq(variables['Build.Reason'], 'Schedule')
then you are reminded to question whether the condition was intended to include failing/cancelled jobs or not.
Changing it to the long version takes away the risk of that mistake.