IF ANY bl THEN

Runs the ops nested underneath it when the job is running against one of the environments you pick. The palette lists this op as IF ANY env THEN.

It is the standard way to keep production-only work out of a test run, and the reason to prefer it over a hand-written comparison is that you pick environments from a list rather than typing codes that later drift. What you pick is stored as a resource reference and turned into an environment code later, which has consequences described below.

Fields

Environment

The environments the block applies to. The field takes more than one, and the block runs when the job's environment is any of them. The form marks it required, so you cannot leave it empty when configuring the op through the designer.

The picker lists environment resources and, mixed in with them, global variables. Do not pick a variable here. This op does not resolve variables, so a variable chosen from the list ends up as a check against an environment literally named ${your_variable}, which no job ever matches. The block then never runs and nothing in the log explains why. To drive the choice from a variable, test the bl value instead with IF var condition THEN, whose Value field does expand ${var}.

When the codes are worked out

The environments you pick are stored as resource references, and those references are turned into environment codes at the moment the rule is prepared for running, which happens the first time the rule runs after you save it. The result is kept until the rule changes again.

Two consequences follow. Changing an environment's code on the resource does not reach rules that were built with the old code, so open and save each rule that mentions it. And a reference that no longer resolves to anything, after an environment resource is deleted, is used as a code in its own right, which means the op compares the job environment against a reference string and never matches.

How the comparison behaves

The job's current environment code is compared as exact text, case sensitive, against each of the codes. The job puts that code in the stash before the first op of the rule runs, so it is always available inside a job. When nothing has put an environment there, which is the case for a rule running outside a job, the condition is false rather than an error.

An op that reached the rule with no environments picked, through an import or a hand-edited tree, is always false.

What it does at run time

The op appears in the job log as a step under whatever you named it, and it is one of the points at which a cancel request on the job is noticed. It writes nothing into the stash.

ELSE and ELSIF condition THEN attach directly after it and cover the environments you did not pick.

On a rollback pass the test is evaluated again. The job environment does not change during a run, so the same branch is taken both ways.

Combining with other ops

IF var condition THEN with an IN row against bl does the same test from the other direction: you type the codes rather than picking resources. That costs you the resource link. In exchange you get Ignore case and ${var} expansion on the value, plus the option of combining the environment test with other conditions inside one op.

IF var in LIST THEN against bl is the simplest equivalent when all you want is a short fixed list of codes, at the price of an exact, case-sensitive match.

Nest FAIL inside to stop a job that reached an environment it should never have been created for.

Examples

Restrict an approval step to the two environments that need it.

Environment   PROD, PRE

-> Request approval

Keep a destructive cleanup out of production by inverting the test with an ELSE.

IF ANY env THEN   PROD
  -> LOG Message   "cleanup skipped in production"
ELSE
  -> Delete the staging directory