Publish files to the artifacts repository

Copies one file from the Clarive server filesystem into a local artifact repository and adds it to the artifact index. Once published, the file is downloadable over HTTP and appears in the artifact browser under the repository it belongs to.

Reach for it when the file has to outlive the job that produced it. Publish local file to log attaches a copy to the job log instead, and that copy disappears the first time the log is purged. Ship File Remotely sends the file to a target node rather than into a repository. This op is the one that produces a stable URL.

Fields

Repository

The local artifact repository that receives the file. Pick one from the list, which offers every local artifact repository resource defined in the system, followed by the variables declared as holding a repository of that type, shown as variable: ${name}.

One repository per op. To publish the same file into two repositories, add the op twice.

The picker stores a resource id, but the op also accepts a repository name, so a variable holding either form resolves. A value that matches neither stops the rule with an error quoting the value you gave.

The destination on disk is the repository's own root directory joined with Path. Nothing on this form changes that root; it lives on the repository resource. See Artifact Repository Manager for how the root directory and the URL prefix are set.

Required. The form will not let you save it empty, and a ${var} that expands to nothing stops the rule with the same message.

Path

Where the file lands inside the repository, written relative to the repository root. This is a full destination path including the file name, not a target directory. Write /myapp/1.4/bar.zip to publish a file called bar.zip.

End the value with a slash and the op half works. The file is copied into that directory under its own name, but the artifact index and the returned URL both point at the directory rather than at the file, so the artifact never shows up in the browser under a name anyone can download. Always name the file.

${var} placeholders expand against the stash, so /${project}/${bl}/${artifact_name} is the usual shape.

Directories in the path that do not exist yet are created, the repository root included.

Leading and trailing spaces survive. A value typed as /${project}/bar.zip with one stray space after the extension publishes a file whose name ends in a space, and nothing asking for bar.zip will ever match it. Check the end of this field first when a published artifact refuses to download.

Required. The form will not let you save it empty, and a ${var} that expands to nothing stops the rule with the same message.

Origin

The file to publish, as a path on the Clarive server filesystem. ${var} placeholders expand, so ${job_dir}/artifact/${artifact_name} reads a file the job produced.

The file must exist when the op runs. A missing origin stops the rule with an error naming the path it looked for, after variable expansion, so the message tells you what the placeholders turned into.

One file per op. Point Origin at a directory and nothing is copied. Wrap the op in FOREACH file/item to publish a set of files, or pack them first with Zip local path.

Inside a rulebook run, this path is taken as relative to the rulebook workspace. That applies to absolute paths as well: /tmp/bar.zip is read from tmp/bar.zip inside the workspace, with the leading slash absorbed. Outside a rulebook run the path is used as written.

Required. The form will not let you save it empty, and a ${var} that expands to nothing stops the rule with the same message.

What the op gives back

The op returns the public download URL of the file it published. Put a name in the op's Return Key property to capture it. With Return Key set to published, later ops read ${published.url}. Set Return Key to = and the URL lands in the stash as ${url}, which is shorter but collides with anything else called url.

The URL is assembled as the Clarive base URL, then /artifacts/repo/, then the repository's URL prefix, then the value of Path. It is built from what you configured, not from what ended up on disk, so a URL returned by an op that published to the wrong place still looks valid.

Failure and rollback

A blank field, a repository that cannot be found and an origin that does not exist each stop the rule before anything is copied, with a message naming the value that was wrong. Wrap the op in TRY statement with CATCH statement when a publishing failure should not take the whole job down.

A copy that the filesystem refuses is a different story, because the copy itself reports nothing. The rule stops one step later, when the op tries to index a file that is not where it expected, and the message you get talks about the indexing rather than the copy. Worse, if an older file is already sitting at that destination the indexing succeeds, the op reports success and hands back a URL that downloads the stale file.

Publishing is not undone on rollback. The op has no reverse action, so a rolled-back job leaves the published file where it is, and the rollback pass runs the op a second time unless you untick Run Rollback in the op properties panel. When that matters, publish into a path carrying the job id or the revision, so a re-run never overwrites a good artifact.

An existing file at the destination is overwritten with no warning and no log line. The op writes nothing to the job log on success either; the evidence that it ran is the new entry in the artifact browser and the returned URL.

Publishing raises an event carrying the repository name and the path, which an event rule can subscribe to. That is the hook for telling an external system that a new artifact landed. Look for it under Artifact Deployed Remotelly in the event list, which is the entry for publishing from a rule despite how it reads.

Combining with other ops

Produce the file first. Run command or local script builds it, Write local file writes it out of the stash, and Zip local path packs a directory into one archive this op can take.

To publish a directory one file at a time, put this op inside FOREACH file/item and reference the loop variable in Origin.

Once you have captured the URL, hand it to Send a notification or write it onto a topic so people can find the build output later.

Reports follow the same pattern, and the walkthrough is in Publish a static report.

Examples

Publish a build artifact into a per-project, per-environment layout.

Repository   myapp_releases
Path         /${project}/${bl}/${artifact_name}
Origin       ${job_dir}/artifact/${artifact_name}

Publish a generated report and capture the link for a later op. Return Key sits on the op properties panel, not on this form.

Repository   myapp_releases
Path         /reports/${job_name}/coverage.html
Origin       ${job_dir}/reports/coverage.html
Return Key   report

The next op reads ${report.url}.

Publish several files by nesting the op in a loop over a stash list.

FOREACH file/item   over ${built_files}   as foo_file
  Repository   myapp_releases
  Path         /myapp/${version}/${foo_file}
  Origin       ${job_dir}/dist/${foo_file}