Use Placeholders in Upload, Download, Copy, and Move Commands

JFrog CLI provides flexibility in how you download, upload, copy, or move files through the use of wildcard or regular expressions with placeholders.

Any wildcard expression enclosed in parentheses in the source path can be matched with a corresponding placeholder (for example, {1}) in the target path. This allows you to dynamically determine the destination path and filename for an artifact.

To use placeholders in upload, download, copy, or move commands:

1. Wrap the part of the source pattern you want to capture in parentheses.
2. Use {1}, {2}, and so on in the target path to refer to each capture group, in order.
3. Run the appropriate jf rt command with your pattern and target (see Using Placeholder Examples).

📘

Prerequisites

Before running any command on this page:

• A JFrog server must be configured: run jf config add to set one up.
• The target (and source, for copy/move) repositories must already exist in Artifactory.
• For upload examples, the matching local files must be present in the current working directory.
• Use --dry-run to preview resolved paths before committing to an actual upload. See Relevant Flags for details.

How Placeholders Work

Using Placeholder Examples

Example 1: Upload Files into Dynamically Named Directories

This example uploads each .tgz file from the source into a new directory in the target repository that matches the file's base name. For example, the file froggy.tgz is uploaded to my-local-repo/froggy/, which creates the froggy folder in Artifactory.

jf rt u "(*).tgz" my-local-repo/{1}/ --recursive=false

Breakdown:

Result:

👍

Tip

Use --dry-run to preview the resolved target paths before uploading:

Bash

jf rt u "(*).tgz" my-local-repo/{1}/ --recursive=false --dry-run

No files are uploaded. The CLI prints the paths it would have used, letting you verify the placeholder logic is correct.

Example 2: Upload Files with Modified Names

This example uploads all files with names that begin with frog to the frogfiles folder, appending the suffix -up to each filename. For example, a file named froggy.tgz is renamed to froggy.tgz-up.

jf rt u "(frog*)" my-local-repo/frogfiles/{1}-up --recursive=false

Breakdown:

Result:

Example 3: Organize Uploaded Files by Extension

This example uploads all files from the current directory into the my-local-repo repository, placing them into subdirectories named after their file extensions.

jf rt u "(*).(*)" my-local-repo/{2}/{1}.{2} --recursive=false

Breakdown:

Result:

📘

Note

The (*) wildcard matches any characters including hyphens. A file like myapp-sources.jar is captured as group 1 = myapp-sources and group 2 = jar, and is uploaded to my-local-repo/jar/myapp-sources.jar. Only the last dot is treated as the separator between the two groups.

Example 4: Copy Files and Append a Suffix

This example copies all .zip files from the rabbit/ directory in the source-frog-repo to the same path in the target-frog-repo and appends .cp to each copied filename.

jf rt cp "source-frog-repo/rabbit/(*.zip)" target-frog-repo/rabbit/{1}.cp

Breakdown:

Result:

Command Reference

Supported Commands

Placeholders are supported in the following commands:

Relevant Flags

Advanced Usage

Download with Placeholders

Placeholders work in downloads too. The following example downloads all .tgz files from my-local-repo and recreates a local directory per artifact base name, mirroring the structure used in Example 1:

jf rt dl "my-local-repo/(*).tgz" ./{1}/ --recursive=false

Using Regular Expressions with Placeholders

When using --regexp, you can use regex capture groups instead of wildcard patterns:

jf rt u "(.+)-sources\.jar" libs-release-local/{1}/ --regexp

This captures the artifact name before -sources.jar and uses it as a directory.

Multiple Capture Groups

You can use multiple capture groups and reference them in any order in the target path. This lets you restructure the directory hierarchy of artifacts as part of the upload.

The following example reads files organized as <org>/<version>/<artifact>.jar locally and uploads them into my-repo/<artifact>/<org>/<version>/, effectively swapping the directory order:

jf rt u "(*)/(*)/(*).jar" my-repo/{3}/{1}/{2}.jar

📘

Note

Groups are numbered left to right from the source pattern. {1} is the first (*), {2} the second, and so on. You can reference them in any order — or omit them — in the target path.

File Spec Usage

Placeholders also work in File Specs. Save the JSON below to a file (for example, upload-spec.json), then pass it to the upload command using --spec:

{
  "files": [
    {
      "pattern": "(*).tgz",
      "target": "my-local-repo/{1}/",
      "recursive": "false"
    }
  ]
}

jf rt u --spec upload-spec.json

File Specs are useful when you need to express complex multi-pattern uploads or reuse the same pattern across scripts. All placeholder syntax supported in inline commands works identically in File Specs.

Troubleshooting

Pattern matches no files

If your pattern matches zero files, the command exits 0 with no output and no error. To catch this in CI pipelines, add --fail-no-op:

jf rt u "(*).tgz" my-local-repo/{1}/ --recursive=false --fail-no-op

Exit code 2 is returned when no files are matched, signaling the pipeline to fail.

Upload retries on failure

When an upload fails (for example, due to a transient network error), the CLI automatically retries up to 3 times per file. You will see [Warn] (Attempt N) messages in the output for each retry. This is expected behavior. To adjust:

• --retries N — set the number of retry attempts (default: 3)
• --retry-wait-time 5s — add a pause between retries (accepts s for seconds, ms for milliseconds)

Verifying placeholder resolution

Use --dry-run to print the resolved target paths without uploading anything:

jf rt u "(*).(*)" my-local-repo/{2}/{1}.{2} --recursive=false --dry-run