ELSIF condition THEN

Adds another test to a branch that an IF op has already opened. The ops nested underneath run when every test above this one came back false and this one comes back true. Chain as many as you need and close with ELSE to catch everything left over.

The test is written as Perl. There is no language choice here and no condition builder, which makes this the lowest-level way to extend a branch. If the extra test is a plain comparison against a stash value, a nested IF var condition THEN inside an ELSE reads better and needs no code.

Fields

ELSIF has no configuration form. Its Config tab opens a YAML editor holding a single key.

condition

The test, written as Perl. It goes into the rule exactly as you typed it, so it has to be a valid expression, and the branch is taken when its result is true.

A fresh ELSIF arrives with condition: 1, which is always true. Leave it alone and this arm is taken every time the chain reaches it, so any ELSIF or ELSE below it never gets a look in. Clear the key to nothing and the rule stops working altogether, failing when it starts rather than when execution reaches the op.

The stash is in scope as $stash, and a key reads as $$stash{name}. Nested values follow the same shape, so $$stash{topic}{title} reaches into a loaded topic. This field does no ${var} expansion; a ${var} written here stays text.

Only Perl is accepted. When you want JavaScript for the test, restructure the chain so the JavaScript lives in a nested IF condition THEN, which does offer the language choice.

Placement

The op above an ELSIF, at the same level of the tree, has to be an IF op or another ELSIF. Anything else and the rule refuses to start, with a message naming the op and stating that it is not after an IF block. Ops you have unticked in the Enabled option are removed before the pairing is worked out, so a disabled op sitting between the two does not break the chain.

Tests run top to bottom and stop at the first one that is true. Put narrow cases above broad ones. A broad test placed early makes everything under it unreachable and nothing warns you.

Options tab

The Options tab is nearly empty on this op, and on every other op that opens or continues an IF chain. Return Key, Needs Rollback?, Needs Rollback Key, Run Forward, Run Rollback, Timeout, Semaphore Key, Parallel Mode, Error Handling with its four trap settings, Sub Name and Stage Name are all hidden. Each of them would open a block around the op, and a chain does not survive a block opening between one arm and the next. Put those settings on the ops nested inside the branch. They are described in Rule Palette.

What is left on the tab is Enabled and Debug Mode. Of the three Debug Mode values, avoid Op Trace + Stash Dump here. It prints the stash before and after the op, and those two lines land between the arms, so the rule will not start. Op Trace is safe because it does nothing at all.

A rule that arrived by import can still carry one of the hidden settings on the IF above, since the designer is the only thing stopping you. The rule then refuses to start with a message about the op following an IF in rollback, error trap, parallel mode or closure.

What it does at run time

An ELSIF does not register itself as a step. Its name never shows in the job log and never reaches the monitor, and the cancel request that is checked at every other op is not checked here. Only the ops nested inside it appear.

It writes nothing into the stash by itself, though the Perl you write can change stash values. A condition with a side effect fires once per evaluation, and it does not fire at all when an earlier test already matched.

An error raised by the code stops the rule, and with it the job. The test is not treated as false.

On a rollback pass the whole chain is evaluated again against the stash as it stands at that moment, so the arm chosen on the way back can differ from the one chosen on the way out.

An ELSIF with nothing nested inside it is accepted. It absorbs the case and runs nothing, which is occasionally deliberate and more often a leftover.

Combining with other ops

Open the chain with IF var condition THEN when the first test is a plain stash comparison, then add ELSIF arms for the cases that need real code. The two mix freely in one chain.

Close with ELSE so that an input you did not anticipate lands somewhere you control instead of falling through unnoticed.

Server CODE is the op for work that is itself code rather than a decision. Keep ELSIF conditions to one expression and push anything longer into a server code op that leaves its answer in the stash.

Examples

Split a job three ways on a counter an earlier op left behind.

IF var condition THEN
  When: All
    retries   EQUALS   0   (Numeric)
  -> Run deploy
ELSIF   condition: $$stash{retries} < 3
  -> Wait, then run deploy
ELSE
  -> FAIL   "too many retries"

Branch on something the condition builder cannot reach, such as how many entries a list in the stash holds.

ELSIF   condition: scalar @{ $$stash{changed_files} || [] } > 20
  -> Run the full test suite