IF EXISTS nature THEN

Runs the ops nested underneath it when the current project has changed items belonging to one nature, and while they run it fills the stash with the paths of those items. The palette lists this op as FOR nature DO.

Despite the label it is not a loop. It handles one nature and runs its block at most once. What makes it different from IF ANY nature THEN is the stash it sets up: that op only branches, this one hands the block a ready-made list of file paths to work on.

It only works in the middle of a job that has been prepared for it. Put it inside FOR projects with changes DO, and run Load Nature Items earlier in the rule so that the natures have been worked out. The two requirements fail very differently. Outside the project loop the rule will not even compile, and every run of it stops on an error about an undeclared project before a single op executes. Without the nature load the rule runs fine and the block is skipped in silence.

Fields

Nature

The nature to look for. The picker lists nature resources and the variables declared to hold one, so the choice can come from configuration instead of being pinned in the rule. A variable picked here is stored as ${name} and expanded before the lookup. It matches whether it resolves to the nature's name or to its resource id, since both are registered when the natures are worked out.

One nature per op. A rule that arrived from an import carrying several uses the first and ignores the rest.

Leave it empty and nothing matches, so the block never runs.

Cut Path

The leading part of each item path to strip before the paths are handed to the block. It defaults to /, which removes the leading slash and leaves a path relative to the repository root.

The value is matched against the start of each path as a pattern, not as plain text, so . and * and the rest behave as pattern characters. A literal dot in a directory name needs escaping if you care about precision. ${var} placeholders are expanded before the match, so ${project}/ and similar are fine.

An item whose path does not start with the cut path is dropped from the lists rather than passed through uncut, so a cut path that matches half your items quietly halves the work the block does. If nothing at all survives the cut, the job stops with an error naming the cut path you typed.

What the block can read

While the nested ops run, these values are in the stash. They are set on the way in and taken away again when the block ends, so the ops after this op cannot see them.

Value	What it holds
current_nature	the nature resource that matched
nature_items	the changed items of this nature in the current project, added and deleted alike
nature_item_paths	the cut paths of the items that were added or changed
nature_item_paths_del	the cut paths of the items that were deleted
nature_items_comma	the added and changed paths joined with commas
nature_items_quote	the same paths, each in single quotes and separated by spaces, ready for a command line

The nature's own variables for the environment the job is running in are merged in as well, under the names you gave them on the nature resource. They are scoped to the block in the same way, so a nature variable and a job variable of the same name do not fight beyond the end of the block.

When the nature matches and has items, the job log gets an info line reading Nature Detected with the nature name, carrying nature_items, nature_item_paths, nature_items_comma and nature_items_quote alongside it. The deleted paths are not attached to that line. You cannot turn the line off, and it is the fastest way to confirm the op fired at all.

Silent no-ops

Two configurations look right and do nothing.

The op placed before Load Nature Items, or in a rule that never runs it, finds nothing, because no nature has been worked out yet for any item.

The nature detected, but with no items in this particular project, skips the block without a word. That happens routinely in multi-project jobs where only one project carries files of that nature.

Misplacing the op relative to FOR projects with changes DO is not one of these. That one is caught when the rule is compiled and reported as an error.

Combining with other ops

IF ANY nature THEN is the cheap test when all you want is a yes or no across several natures and you do not need the paths.

APPLY NATURE loads a nature's configuration variables without the item paths, for the cases where the nature is a source of settings rather than a set of files.

Inside the block, Run a remote script and Ship a File Remotely are the usual consumers. Pass ${nature_items_quote} to a command line that takes a list of files, and ${nature_item_paths_del} to whatever handles removals.

ELSE attaches directly after this op, and it only covers the case where the nature was never detected for the current project. A nature that was detected but has no items here runs neither the block nor the ELSE.

Examples

Compile the source files of one nature on a remote server, with the repository root stripped from each path.

Nature     java-sources
Cut Path   /

-> Run a remote script   build.sh ${nature_items_quote}

Deploy database scripts kept under a fixed folder, cutting that folder off the front so the remote side receives bare file names.

Nature     sql-scripts
Cut Path   /db/scripts/

-> Ship a File Remotely   ${nature_items_comma}