Delete Local File
Removes a single file from inside the job directory on the Clarive server. Use it to clean up a temporary script, a generated SQL file or a credentials file that a step wrote and a later step should not be able to read.
It deletes one file. For a whole folder and everything under it, use Delete Local Directory.
Fields¶
The op has no form. Its Config tab carries the standard Name box, which relabels the op in the
rule tree, and a YAML editor that opens empty. You type the keys yourself, and the op reads exactly
one:
file: bar/tmp.sql
Any other key you add is stored with the rule and ignored.
file¶
Path of the file to remove, relative to the job directory. Required. Leave the key out and the op
stops the job with Missing parameter file. Writing file: with nothing after it is not the same
thing: the empty value resolves to the job directory itself, which exists but is not a file, so the
job stops with a delete error instead.
The value expands ${var} placeholders, so file: ${project}/generated.sql works.
The path is joined onto the job directory¶
Whatever you type is appended to the job directory. A leading slash does not make the path absolute;
it is stripped and the rest is joined on, so /tmp/foo.sql resolves to
<job_dir>/tmp/foo.sql and not to /tmp/foo.sql.
The prefix is the only guard, and it is not a sandbox. .. segments are left in the path and the
system follows them, so file: ../other_job/secret.txt deletes a file in a sibling directory and
file: ../../../etc/foo.conf walks off the job tree entirely, subject only to the file permissions
of the account the server runs as. Nothing warns you, and the job log prints the path with the ..
still in it. Keep ${var} values that reach this field under your control.
Failure¶
The file has to be there. A path that does not exist stops the job with
Could not find file, which makes the op unsuitable as an unconditional cleanup step: a rule that
deletes a file only some runs produce fails on the runs that did not produce it.
Two ways round that. Set Error Handling to Ignore Errors on the Options tab, which is the short
answer for a cleanup step. Or test for the file first with
IF condition THEN and nest the delete inside it.
A file that exists but cannot be removed, because of permissions or because the path names a directory, also stops the job, with the reason the system gave appended to the message. Pointing this op at a folder gets you that error every time, never an empty folder.
A symbolic link is removed as a link. The file it points at is left alone.
What the job log shows¶
One line at info level on success: Successfully delete file followed by the full resolved path in
quotes. Reading that path is the quickest way to confirm the job directory prefix landed where you
expected. Nothing is logged before the delete, so a failing run tells you only that the path was
missing or refused.
Rollback¶
The op has no rollback behaviour and keeps no copy. A deleted file is gone. On a rollback pass the op
runs again, which normally fails because the file is already deleted, so clear Run Rollback on the
Options tab for any cleanup step.
Combining with other ops¶
The natural pairing is with Write local file: write a script into
${job_dir}, run it with Run command or local script, then remove it here.
Put IF condition THEN in front when the file is only sometimes there. Put the whole sequence inside TRY statement when the cleanup must not be able to fail the job.
For the folder rather than one file, Delete Local Directory removes a tree in one step. Note that Init Job Home already clears the job directory at the start of each job, so cleanup at the end is about not leaving secrets on disk rather than about reclaiming space.
Examples¶
Remove a generated SQL file after the step that used it.
file: deploy.sql
Remove a file whose name comes from the stash, inside a project folder.
file: ${project}/${artifact_name}.tmp
Cleanup that must not fail the job when the file was never created. Set Error Handling to
Ignore Errors, then:
file: bar/credentials.properties