Skip to content

Load files/items into stash

Collects a list of paths on the Clarive server and hands it back as a single value, so that a later op can test it or walk it. It looks in one of three places: a directory listing, a whole directory tree, or the item paths of the nature currently being processed.

It shares its form with FOREACH file/item. The loop op walks the paths one at a time with the nested ops inside it; this op gathers the same paths into one list and stops. Use this one when you want the list itself, and the loop op when you want to act on each entry.

Path Mode one directory whole tree nature items candidates filtered by Dir Mode Include Paths Exclude Paths list Return Key no Return Key set: the list is computed and thrown away

Fields

Variable

This op does not read the name you type here.

The field belongs to the loop version of the form, where it names the loop variable. In this op the list reaches the stash only through Return Key, in the op's properties panel. Filling in Variable and leaving Return Key empty is the most common way to end up with a rule that scans the disk and quietly discards the result.

Set Return Key to the name you want, for example my_files, and read it back as ${my_files}.

Path

Base path to search, expanded from the stash, so ${job_dir}/${project}/dist works.

It is required for both file modes. Leave it blank and the op stops the job with a message about the root path not being configured.

A path with no * or ? in it must exist on disk, or the op stops the job. A path containing either of those characters skips that check and is treated as a pattern.

In Nature Items mode the field means something different: it is optional, and when filled it is stripped off the front of each returned path rather than searched. The existence check still applies there, so a prefix you type by hand has to be a real directory unless it carries a wildcard.

Path Mode

Choice What it lists
Files, non Recursive the direct contents of Path, one level deep
Recursive Files everything under Path, at any depth
Nature Items the item paths of the nature currently in scope

Default is Files, non Recursive.

In Files, non Recursive, a Path that points at a directory lists that directory's children. A Path that contains a wildcard is expanded as a shell pattern, so ${job_dir}/*/target/*.jar works and no other mode gives you that.

Recursive Files walks the tree and cannot take a wildcard; give it a plain directory. Pointing it at a single file stops the job with a directory error.

Nature Items only has anything to work with inside IF EXISTS nature THEN, which is the op that puts the current nature's item paths in scope, and only for the length of its block. Outside the block the list comes back empty and nothing warns you. APPLY NATURE is not a substitute: it sets a different list that this mode does not read, so this op finds nothing after it.

The paths it picks up have already been trimmed by that block's Cut Path. They are resolved under the job directory, and entries that no longer exist on disk are dropped, so items deleted by the changeset do not appear.

Dir Mode

Choice Meaning
Files only plain files, no directories
Files and Directories both
Only Directories directories, no files

Default is Files only.

Files and Directories behaves as written in Recursive Files and Nature Items modes. In Files, non Recursive it does not: anything other than Files only returns directories alone there, so a flat listing with Files and Directories gives you the subdirectories and none of the files. When you need both from one directory, run the op twice and join the two lists.

In Recursive Files, the Path directory itself counts as one of the results under Only Directories and Files and Directories. Exclude it with a filter row if that matters.

Return relative paths?

Off by default. When ticked, the leading Path is stripped from every entry, so /opt/jobs/DEV-1/myapp/bar/baz.war comes back as bar/baz.war. Stripping happens after the filters run, so the rows under Filters are still matched against the full path.

Ticking it with no Path filled in returns an empty list. That combination is reachable in Nature Items mode, where Path is optional, and it is a silent no-op: the op succeeds and hands back nothing.

In Nature Items mode with Path filled in the checkbox changes nothing, because those paths were made relative to Path before the checkbox was consulted.

Filters

A two-tab panel. Each tab is a one-column grid with Add and Delete buttons above it. Add inserts a row pre-filled with .*; click the row to edit it.

Include Paths

Regular expressions, one per row. A path survives when it matches at least one row. An empty grid means everything survives, which is the normal setting.

These are regular expressions and not shell globs. *.jar does not do what you expect; write \.jar$. A row matches anywhere in the path string and is not anchored for you, so /target/ filters by directory. In Nature Items mode with Path filled in, the paths reaching the filters are already relative, and a row that starts with a slash matches nothing.

Rows expand ${var} placeholders against the stash before they are compiled, so /${module}/ is a usable row.

For a case-insensitive row, or any other regex flag, wrap the pattern in double exclamation marks and put the flags after: !!\.JAR$!!i.

Exclude Paths

Same grid, applied after the includes. A path matching any row is dropped, whatever the include rows said. A row here beats a row there.

Only the drops reach the job log, as one debug entry listing the full include and exclude sets followed by a line per discarded path naming the rule responsible. A run where every path survived writes nothing, so silence means no filtering happened rather than no logging.

What you get back

A list of path strings, with no de-duplication.

Order depends on the mode. Files, non Recursive is a shell-style expansion, so it comes back alphabetically and never includes a name that begins with a dot. Recursive Files comes back in directory order, which is arbitrary, and it does pick up dot files and dot directories. Nature Items follows the order of the nature's own item list.

Files, non Recursive and Recursive Files return absolute paths unless Return relative paths? is ticked. Nature Items returns paths already made relative to Path when you filled it in, and absolute job-directory paths when you did not.

An empty result is not an error. The op reports success, and a later op that iterates the list runs zero times.

Combining with other ops

Set Return Key, then walk the result with FOREACH CI or test it with IF var condition THEN using IS EMPTY before you commit to a deployment step.

When all you want is to act on each file, skip this op entirely and use FOREACH file/item, which has the same form and loops directly.

For nature-driven lists, put Load Nature Items earlier in the rule and nest this op inside IF EXISTS nature THEN.

To send the files you found, follow with Ship File Remotely, which accepts include and exclude patterns of its own in the same regex style. To rewrite their contents first, use Replace Strings.

Examples

Every jar produced by a build, anywhere under the project checkout, put in the stash as my_files.

Return Key             my_files
Path                   ${job_dir}/${project}
Path Mode              Recursive Files
Dir Mode               Files only
Return relative paths? no
Include Paths          \.jar$
Exclude Paths          /test/

The immediate subdirectories of a deploy root, to loop over one deployment per module.

Return Key             module_dirs
Path                   ${job_dir}/myapp/modules
Path Mode              Files, non Recursive
Dir Mode               Only Directories
Return relative paths? yes

The files of the nature being processed, relative to the project checkout, ready to hand to a packaging step. Place it inside the IF EXISTS nature THEN block.

Return Key             nature_files
Path                   ${job_dir}/${project}
Path Mode              Nature Items
Dir Mode               Files only
Exclude Paths          \.bak$