JFrog CLI v2

Overview

JFrog CLI v2 was launched in July 2021. It includes changes to the functionality and usage of some of the legacy JFrog CLI commands. The changes are the result of feedback we received from users over time through GitHub, making the usage and functionality easier and more intuitive. For example, some of the default values changed, and are now more consistent across different commands. We also took this opportunity for improving and restructuring the code, as well as replacing old and deprecated functionality.

Most of the changes included in v2 are breaking changes compared to the v1 releases. We therefore packaged and released these changes under JFrog CLI v2, allowing users to migrate to v2 only when they are ready.

New enhancements to JFrog CLI are planned to be introduced as part of V2 only. V1 receives very little development attention nowadays. We therefore encourage users who haven't yet migrated to V2, to do so.

List of changes in JFrog CLI v2

1. The default value of the --flat option is now set to false for the jfrog rt upload command.

2. The deprecated syntax of the jfrog rt mvn command is no longer supported. To use the new syntax, the project needs to be first configured using the jfrog rt mvnc command.

3. The deprecated syntax of the jfrog rt gradle command is no longer supported. To use the new syntax, the project needs to be first configured using the jfrog rt gradlec command.

4. The deprecated syntax of the jfrog rt npm and jfrog rt npm-ci commands is no longer supported. To use the new syntax, the project needs to be first configured using the jfrog rt npmc command.

5. The deprecated syntax of the jfrog rt go command is no longer supported. To use the new syntax, the project needs to be first configured using the jfrog rt go-config command.

6. The deprecated syntax of the jfrog rt nuget command is no longer supported. To use the new syntax, the project needs to be first configured using the jfrog rt nugetc command.

7. All Bintray commands are removed.

8. The jfrog rt config command is removed and replaced by the jfrog config add command.

9. The jfrog rt use command is removed and replaced with the jfrog config use.

10. The --props command option and props file spec property for the jfrog rt upload command are removed, and replaced with the --target-props command option and targetProps file spec property respectively.

11. The following commands are removed

    Copy

    jfrog rt release-bundle-create
    jfrog rt release-bundle-delete
    jfrog rt release-bundle-distribute
    jfrog rt release-bundle-sign
    jfrog rt release-bundle-update

    and replaced with the following commands respectively

    Copy

    jfrog ds release-bundle-create
    jfrog ds release-bundle-delete
    jfrog ds release-bundle-distribute
    jfrog ds release-bundle-sign
    jfrog ds release-bundle-update

12. The jfrog rt go-publish command now only supports Artifactory version 6.10.0 and above. Also, the command no longer accepts the target repository as an argument. The target repository should be pre-configured using the jfrog rt go-config command.

13. The jfrog rt go command no longer falls back to the VCS when dependencies are not found in Artifactory.

14. The --deps, --publish-deps, --no-registry and --self options of the jfrog rt go-publish command are now removed.

15. The --apiKey option is now removed. The API key should now be passed as the value of the --password option.

16. The --exclude-patterns option is now removed, and replaced with the --exclusions option. The same is true for the excludePatterns file spec property, which is replaced with the exclusions property.

17. The JFROG_CLI_JCENTER_REMOTE_SERVER and JFROG_CLI_JCENTER_REMOTE_REPO environment variables are now removed and replaced with the JFROG_CLI_EXTRACTORS_REMOTE environment variable.

18. The JFROG_CLI_HOME environment variable is now removed and replaced with the JFROG_CLI_HOME_DIR environment variable.

19. The JFROG_CLI_OFFER_CONFIG environment variable is now removed and replaced with the CI environment variable. Setting CI to true disables all prompts.

20. The directory structure is now changed when the jfrog rt download command is used with placeholders and --flat=false (--flat=false is now the default). When placeholders are used, the value of the --flat option is ignored.

21. When the jfrog rt upload command now uploads symlinks to Artifactory, the target file referenced by the symlink is uploaded to Artifactory with the symlink name. If the --symlink options is used, the symlink itself (not the referenced file) is uploaded, with the referenced file as a property attached to the file.

Installation

To download the executable, please visit the JFrog CLI Download Site.

You can also download the sources from the JFrog CLI Project on GitHub where you will also find instructions on how to build JFrog CLI.

The legacy name of JFrog CLI's executable is jfrog. In an effort to make the CLI usage easier and more convenient, we recently exposed a series of new installers, which install JFrog CLI with the new jf executable name. For backward compatibility, the old installers will remain available. We recommend however migrating to the newer jf executable name.

JFrog CLI v2 "jf" installers

The following installers are available for JFrog CLI v2. These installers make JFrog CLI available through the jf executable.

Debian

# Create the keyrings directory if it doesn't exist
sudo mkdir -p /usr/share/keyrings;

# Download and save the JFrog GPG key to a keyring file
wget -qO - https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-debs/keyPairs/primary/public | sudo gpg --dearmor -o /usr/share/keyrings/jfrog.gpg

# Add the JFrog repository to your APT sources with the signed-by option
echo "deb [signed-by=/usr/share/keyrings/jfrog.gpg] https://releases.jfrog.io/artifactory/jfrog-debs focal contrib" | sudo tee /etc/apt/sources.list.d/jfrog.list


# Update the package list
sudo apt update;

# Install the JFrog CLI
sudo apt install -y jfrog-cli-v2-jf;

# Run the JFrog CLI intro command
jf intro;

RPM

# Create and configure the JFrog CLI YUM repository
echo "[jfrog-cli]" > jfrog-cli.repo &&
echo "name=JFrog CLI" >> jfrog-cli.repo &&
echo "baseurl=https://releases.jfrog.io/artifactory/jfrog-rpms" >> jfrog-cli.repo &&
echo "enabled=1" >> jfrog-cli.repo &&
echo "gpgcheck=1" >> jfrog-cli.repo && 

# Import GPG keys for verifying packages
# Note: Two keys are imported for backward compatibility with older versions
rpm --import https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-rpms/keyPairs/primary/public &&
rpm --import https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-rpms/keyPairs/secondary/public &&

# Move the repository file to the YUM configuration directory
sudo mv jfrog-cli.repo /etc/yum.repos.d/ &&

# Install the JFrog CLI package
yum install -y jfrog-cli-v2-jf &&

# Display an introductory message for JFrog CLI
jf intro

Homebrew

brew install jfrog-cli

Install with cUrl

curl -fL https://install-cli.jfrog.io | sh

Download with cUrl

curl -fL https://getcli.jfrog.io/v2-jf | sh

NPM

npm install -g jfrog-cli-v2-jf

Docker

Slim: docker run releases-docker.jfrog.io/jfrog/jfrog-cli-v2-jf jf -v Full: docker run releases-docker.jfrog.io/jfrog/jfrog-cli-full-v2-jf jf -v

Powershell

powershell: "Start-Process -Wait -Verb RunAs powershell '-NoProfile iwr https://releases.jfrog.io/artifactory/jfrog-cli/v2-jf/\[RELEASE\]/jfrog-cli-windows-amd64/jf.exe -OutFile $env:SYSTEMROOT\\system32\\jf.exe'"

Chocolatey

choco install: jfrog-cli-v2-jf

JFrog CLI v2 "jfrog" installers

The following installers are available for JFrog CLI v2. These installers make JFrog CLI available through the jfrog executable.

Debian

wget -qO - https://releases.jfrog.io/artifactory/jfrog-gpg-public/jfrog\_public\_gpg.key | sudo apt-key add - echo "deb https://releases.jfrog.io/artifactory/jfrog-debs xenial contrib" | sudo tee -a /etc/apt/sources.list; apt update; apt install -y jfrog-cli-v2;

RPM

echo "\[jfrog-cli\]" > jfrog-cli.repo; echo "name=jfrog-cli" >> jfrog-cli.repo; echo "baseurl=https://releases.jfrog.io/artifactory/jfrog-rpms" >> jfrog-cli.repo; echo "enabled=1" >> jfrog-cli.repo; rpm --import https://releases.jfrog.io/artifactory/jfrog-gpg-public/jfrog\_public\_gpg.key sudo mv jfrog-cli.repo /etc/yum.repos.d/; yum install -y jfrog-cli-v2;

Homebrew

brew install jfrog-cli

Download with Curl

curl -fL https://getcli.jfrog.io/v2 | sh

NPM

npm install -g jfrog-cli-v2

Docker

Slim: docker run releases-docker.jfrog.io/jfrog/jfrog-cli-v2 jfrog -v Full: docker run releases-docker.jfrog.io/jfrog/jfrog-cli-full-v2 jfrog -v

Chocolatey

choco install jfrog-cli

JFrog CLI v1 (legacy) installers

The following installations are available for JFrog CLI v1. These installers make JFrog CLI available through the jfrog executable.

Debian

wget -qO - https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-debs/keyPairs/primary/public | sudo apt-key add - echo "deb https://releases.jfrog.io/artifactory/jfrog-debs xenial contrib" | sudo tee -a /etc/apt/sources.list; apt update; apt install -y jfrog-cli;

RPM

echo "\[jfrog-cli\]" > jfrog-cli.repo; echo "name=jfrog-cli" >> jfrog-cli.repo; echo "baseurl=https://releases.jfrog.io/artifactory/jfrog-rpms" >> jfrog-cli.repo; echo "enabled=1" >> jfrog-cli.repo; rpm --import https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-rpms/keyPairs/primary/public; rpm --import https://releases.jfrog.io/artifactory/api/v2/repositories/jfrog-rpms/keyPairs/secondary/public sudo mv jfrog-cli.repo /etc/yum.repos.d/; yum install -y jfrog-cli;

Download with cUrl

curl -fL https://getcli.jfrog.io | sh

NPM

npm install -g jfrog-cli-go

Docker

Slim: docker run releases-docker.jfrog.io/jfrog/jfrog-cli jfrog -v Full: docker run releases-docker.jfrog.io/jfrog/jfrog-cli-full jfrog -v

Go

GO111MODULE=on go get github.com/jfrog/jfrog-cli; if \[ -z "$GOPATH" \] then binPath="$HOME/go/bin"; else binPath="$GOPATH/bin"; fi; mv "$binPath/jfrog-cli" "$binPath/jfrog"; echo "$($binPath/jfrog -v) is installed at $binPath";

If you're using JFrog CLI from a bash, zsh, or fish shells, you can install JFrog CLI's auto-completion scripts.

Install JFrog CLI with Homebrew?

If you're installing JFrog CLI using Homebrew, the bash, zsh, or fish auto-complete scripts are automatically installed by Homebrew. Please make sure that your .bash_profile or .zshrc are configured as described in the Homebrew Shell Completion documentation.

Using Oh My Zsh?

With your favorite text editor, open $HOME/.zshrc and add jfrog to the plugin list. For example:

plugins=(git mvn npm sdk jfrog)

Other Installation Methods

To install auto-completion for bash, run the following command and follow the instructions to complete the installation:

jf completion bash --install

To install auto-completion for zsh, run the following command and follow the instructions to complete the installation:

jf completion zsh --install

To install auto-completion for fish, run the following command:

jf completion fish --install

When used with Xray, JFrog CLI offers several means of authentication: JFrog CLI does not support accessing Xray without authentication.

Authenticating with Username and Password

To authenticate yourself using your Xray login credentials, either configure your credentials once using the jf c add command or provide the following option to each command.

Authenticating with an Access Token

To authenticate yourself using an Xray Access Token, either configure your Access Token once using the jf c add command or provide the following option to each command.

Overview

When used with Artifactory, JFrog CLI offers several means of authentication: JFrog CLI does not support accessing Artifactory without authentication.

Authenticating with Username and Password / API Key

To authenticate yourself using your JFrog login credentials, either configure your credentials once using the jf c add command or provide the following option to each command.

For enhanced security, when JFrog CLI is configured to use a username and password / API key, it automatically generates an access token to authenticate with Artifactory. The generated access token is valid for one hour only. JFrog CLI automatically refreshed the token before it expires. The jf c add command allows disabling this functionality. This feature is currently not supported by commands which use external tools or package managers or work with JFrog Distribution.

Authenticating with an Access Token

To authenticate yourself using an Artifactory Access Token, either configure your Access Token once using the jf c add command or provide the following option to each command.

Authenticating with RSA Keys

Note

Currently, authentication with RSA keys is not supported when working with external package managers and build tools (Maven, Gradle, Npm, Docker, Go and NuGet) or with the cUrl integration.

From version 4.4, Artifactory supports SSH authentication using RSA public and private keys. To authenticate yourself to Artifactory using RSA keys, execute the following instructions:

• Enable SSH authentication as described in Configuring SSH.

• Configure your Artifactory URL to have the following format: ssh://[host]:[port] There are two ways to do this:

  • For each command, use the --url command option.

  • Specify the Artifactory URL in the correct format using the jf c add command.

  ---

  Warning Don't include your Artifactory context URL

  Make sure that the [host] component of the URL only includes the hostname or the IP, but not your Artifactory context URL.

  ---

• Configure the path to your SSH key file. There are two ways to do this:

  • For each command, use the --ssh-key-path command option.

  • Specify the path using the jf c add command.

Authenticating using Client Certificates (mTLS)

From Artifactory release 7.38.4, you can authenticate users using a client certificate (mTLS). To do so will require a reverse proxy and some setup on the front reverse proxy (Nginx). Read about how to set this up here.

To authenticate with the proxy using a client certificate, either configure your certificate once using the jf c add command or use the --client-cert-path and--client-cert-ket-path command options with each command.

Note

Authentication using client certificates (mTLS) is not supported by commands which integrate with package managers.

Not Using a Public CA (Certificate Authority)?

This section is relevant for you if you're not using a public CA (Certificate Authority) to issue the SSL certificate used to connect to your Artifactory domain. You may not be using a public CA either because you're using self-signed certificates or you're running your own PKI services in-house (often by using a Microsoft CA).

In this case, you'll need to make those certificates available for JFrog CLI, by placing them inside the security/certs directory, which is under JFrog CLI's home directory. By default, the home directory is ~/.jfrog, but it can be also set using the JFROG_CLI_HOME_DIR environment variable.

Note

1. The supported certificate format is PEM. Make sure to have ONE file with the ending .pem. OR provide as many as you want and run the c_rehash command on the folder as follows :c_rehash ~/.jfrog/security/certs/.

2. Some commands support the --insecure-tls option, which skips the TLS certificates verification.

3. Before version 1.37.0, JFrog CLI expected the certificates to be located directly under the security directory. JFrog CLI will automatically move the certificates to the new directory when installing version 1.37.0 or above. Downgrading back to an older version requires replacing the configuration directory manually. You'll find a backup if the old configuration under .jfrog/backup

JFrog CLI is a compact and smart client that provides a simple interface that automates access to JFrog products simplifying your automation scripts and making them more readable and easier to maintain. JFrog CLI works with JFrog Artifactory, making your scripts more efficient and reliable in several ways:

Advanced upload and download capabilities

JFrog CLI allows you to upload and download artifacts concurrently by a configurable number of threads that help your automated builds run faster. For big artifacts, you can define a number of chunks to split files for parallel download.

JFrog CLI optimizes both upload and download operations by skipping artifacts that already exist in their target location. Before uploading an artifact, JFrog CLI queries Artifactory with the artifact's checksum. If it already exists in Artifactory's storage, the CLI skips sending the file, and if necessary, Artifactory only updates its database to reflect the artifact upload. Similarly, when downloading an artifact from Artifactory, if the artifact already exists in the same download path, it will be skipped. With checksum optimization, long upload and download operations can be paused in the middle, and then be continued later where they were left off.

JFrog CLI supports uploading files to Artifactory using wildcard patterns, regular expressions, and ANT patterns, giving you an easy way to collect all the files you wish to upload. You can also download files using wildcard patterns.

Support for popular package managers and build tools

JFrog CLI offers comprehensive support for popular package managers and builds tools. It seamlessly integrates with package managers like npm, Maven, NuGet, Docker, and more, allowing you to easily manage and publish packages.

Support for Build-Info

Build-Info is a comprehensive metadata Software Bill of Materials (SBOM) that captures detailed information about the components used in a build. It serves as a vital source of information, containing version history, artifacts, project modules, dependencies, and other crucial data collected during the build process. By storing this metadata in Artifactory, developers gain traceability and analysis capabilities to improve the quality and security of their builds. The Build-Info encompasses project module details, artifacts, dependencies, environment variables, and more. It is collected and outputted in a JSON format, facilitating easy access to information about the build and its components. JFrog CLI can create build-info and store the build-info in Artifactory.

Read more about JFrog CLI here.

Overview

This command can be used to verify that Artifactory is accessible by sending an applicative ping to Artifactory.

Commands Params

Examples

Example 1

Ping the configured default Artifactory server.

jf rt ping

Example 2

Ping the configured Artifactory server with ID rt-server-1.

jf rt ping --server-id=rt-server-1

Example 3

Ping the Artifactory server. accessible through the specified URL.

jf rt ping --url=https://my-rt-server.com/artifactory

Overview

To achieve complex file manipulations you may require several CLI commands. For example, you may need to upload several different sets of files to different repositories. To simplify the implementation of these complex manipulations, you can apply JFrog CLI download, upload, move, copy and delete commands with JFrog Artifactory using --spec option to replace the inline command arguments and options. Similarly, you can create and update release bundles by providing the --spec command option. Each command uses an array of file specifications in JSON format with a corresponding schema as described in the sections below. Note that if any of these commands are issued using both inline options and the file specs, then the inline options override their counterparts specified in the file specs.

File Spec Schemas

Copy and Move Commands Spec Schema

The file spec schema for the copy and move commands is as follows:

{
  "files": [
  {
    "pattern" or "aql": "[Mandatory]",
    "target": "[Mandatory]",
    "props": "[Optional]",
    "excludeProps": "[Optional]",
    "recursive": "[Optional, Default: 'true']",
    "flat": "[Optional, Default: 'false']",
    "exclusions": "[Optional, Applicable only when 'pattern' is specified]",
    "archiveEntries": "[Optional]",
    "build": "[Optional]",
    "bundle": "[Optional]",
    "validateSymlinks": "[Optional]",
    "sortBy": "[Optional]",
    "sortOrder": "[Optional, Default: 'asc']",
    "limit": "[Optional],
    "offset": [Optional] }
  ]
}

Download Command Spec Schema

The file spec schema for the download command is as follows:

{
  "files": [
  {
    "pattern" or "aql": "[Mandatory]",
    "target": "[Optional]",
    "props": "[Optional]",
    "excludeProps": "[Optional]",
    "recursive": "[Optional, Default: 'true']",
    "flat": "[Optional, Default: 'false']",
    "exclusions": "[Optional, Applicable only when 'pattern' is specified]",
    "archiveEntries": "[Optional]",
    "build": "[Optional]",
    "bundle": "[Optional]",
    "sortBy": "[Optional]",
    "sortOrder": "[Optional, Default: 'asc']",
    "limit": [Optional],
    "offset": [Optional] }
  ]
}

Create and Update Release Bundle V1 Commands Spec Schema

The file spec schema for the create and update release bundle v1 commands is as follows:

{
"files": [
  {
    "pattern" or "aql": "[Mandatory]",
    "pathMapping": "[Optional, Applicable only when 'aql' is specified]",
    "target": "[Optional]",
    "props": "[Optional]",
    "targetProps": "[Optional]",
    "excludeProps": "[Optional]",
    "recursive": "[Optional, Default: 'true']",
    "flat": "[Optional, Default: 'false']",
    "exclusions": "[Optional, Applicable only when 'pattern' is specified]",
    "archiveEntries": "[Optional]",
    "build": "[Optional]",
    "bundle": "[Optional]",
    "sortBy": "[Optional]",
    "sortOrder": "[Optional, Default: 'asc']",
    "limit": [Optional],
    "offset": [Optional] }
  ]
}

Upload Command Spec Schema

The file spec schema for the upload command is as follows:

{
  "files": [
  {
    "pattern": "[Mandatory]",
    "target": "[Mandatory]",
    "targetProps": "[Optional]",
    "recursive": "[Optional, Default: 'true']",
    "flat": "[Optional, Default: 'true']",
    "regexp": "[Optional, Default: 'false']",
    "ant": "[Optional, Default: 'false']",
    "archive": "[Optional, Must be: 'zip']",
    "exclusions": "[Optional]" }
  ]
}

Search, Set-Props and Delete Commands Spec Schema

The file spec schema for the search and delete commands are as follows:

{
  "files": [
  {
    "pattern" or "aql": "[Mandatory]",
    "props": "[Optional]",
    "excludeProps": "[Optional]",
    "recursive": "[Optional, Default: 'true']",
    "exclusions": "[Optional, Applicable only when 'pattern' is specified]",
    "archiveEntries": "[Optional]",
    "build": "[Optional]",
    "bundle": "[Optional]",
    "sortBy": "[Optional]",
    "sortOrder": "[Optional, Default: 'asc']",
    "limit": [Optional],
    "offset": [Optional] }
  ]
}

Examples

The following examples can help you get started using File Specs.

Example 1

Download all files located under the all-my-frogs directory in the my-local-repo repository to the froggy directory.

{
  "files": [
  {
    "pattern": "my-local-repo/all-my-frogs/",
    "target": "froggy/" }
  ]
}

Example 2

Download all files located under the all-my-frogs directory in the my-local-repo repository to the froggy directory. Download only files which are artifacts of build number 5 of build my-build .

{
  "files": [
    {
      "pattern": "my-local-repo/all-my-frogs/",
      "target": "froggy/",
      "build": "my-build/5"
    }
  ]
}

Example 3

Download all files retrieved by the AQL query to the froggy directory.

{
  "files": [
    {
      "aql": {
        "items.find": {
          "repo": "my-local-repo",
          "$or": [
            {
              "$and": [
                {
                  "path": {
                    "$match": "."
                  },
                  "name": {
                    "$match": "a1.in"
                  }
                }
              ]
            },
            {
              "$and": [
                {
                  "path": {
                    "$match": "*"
                  },
                  "name": {
                    "$match": "a1.in"
                  }
                }
              ]
            }
          ]
        }
      },
      "target": "froggy/"
    }
  ]
}

Example 4

1. All zip files located under the resources directory to the zip folder, under the all-my-frogs repository. AND

2. All TGZ files located under the resources directory to the **tgz folder, under the all-my-frogs repository.

3. Tag all zip files with type = zip and status = ready.

4. Tag all tgz files with type = tgz and status = ready.

{
  "files": [
    {
      "pattern": "resources/*.zip",
      "target": "all-my-frogs/zip/",
      "props": "type=zip;status=ready"
    },
    {
      "pattern": "resources/*.tgz",
      "target": "all-my-frogs/tgz/",
      "props": "type=tgz;status=ready"
    }
  ]
}

Example 5

Upload all zip files located under the resources directory to the zip folder, under the all-my-frogs repository.

{
  "files": [
    {
      "pattern": "resources/*.zip",
      "target": "all-my-frogs/zip/"
    }
  ]
}

Example 6

Package all files located (including subdirectories) under the resources directory into a zip archive named archive.zip , and upload it into the root of the all-my-frogs repository.

{
  "files": [
    {
      "pattern": "resources/",
      "archive": "zip",
      "target": "all-my-frogs/"
    }
  ]
}

Example 7

Download all files located under the all-my-frogs directory in the my-local-repo repository except for files with .txt extension and all files inside the all-my-frogs directory with the props. prefix.`

Notice that the exclude patterns do not include the repository.

{
    "files": [
     {
        "pattern": "my-local-repo/all-my-frogs/",
        "exclusions": ["*.txt","all-my-frog/props.*"]
     }
    ]
}

Example 8

Download The latest file uploaded to the all-my-frogs directory in the my-local-repo repository.

{
    "files": [
     {
        "pattern": "my-local-repo/all-my-frogs/",
        "target": "all-my-frogs/files/",
        "sortBy": ["created"],
        "sortOrder": "desc",
        "limit": 1
     }
    ]
}

Example 9

Search for the three largest files located under the all-my-frogs directory in the my-local-repo repository. If there are files with the same size, sort them "internally" by creation date.

{
    "files": [
     {
        "pattern": "my-local-repo/all-my-frogs/",
        "sortBy": ["size","created"],
        "sortOrder": "desc",
        "limit": 3
     }
    ]
}

Example 10

Download The second-latest file uploaded to the all-my-frogs directory in the my-local-repo repository.

{
    "files": [
     {
        "pattern": "my-local-repo/all-my-frogs/",
        "target": "all-my-frogs/files/",
        "sortBy": ["created"],
        "sortOrder": "desc",
        "limit": 1,
        "offset": 1
     }
    ]
}

Example 11

This example shows how to delete artifacts in artifactory under specified path based on how old they are.

The following File Spec finds all the folders which match the following criteria:

1. They are under the my-repo repository.

2. They are inside a folder with a name that matches abc-*-xyz and is located at the root of the repository.

3. Their name matches ver*

4. They were created more than 7 days ago.

{
  "files": [
    {
      "aql": {
        "items.find": {
          "repo": "myrepo",
          "path": {"$match":"abc-*-xyz"},
          "name": {"$match":"ver*"},
          "type": "folder",
          "$or": [
            {
              "$and": [
                {
                  "created": { "$before":"7d" }
                }
              ]
            }
          ]
        }
      }
    }
  ]
}

Example 12

This example uses Using Placeholders. For each .tgz file in the source directory, create a corresponding directory with the same name in the target repository and upload it there. For example, a file named froggy.tgz should be uploaded to my-local-rep/froggy. (froggy will be created a folder in Artifactory).

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

Example 13

This examples uses Using Placeholders. Upload all files whose name begins with "frog" to folder frogfiles in the target repository, but append its name with the text "-up". For example, a file called froggy.tgz should be renamed froggy.tgz-up.

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

Example 14

The following two examples lead to the exact same outcome. The first one uses Using Placeholders, while the second one does not. Both examples download all files from the generic-local repository to be under the ֿֿmy/local/path/ local file-system path, while maintaining the original Artifactory folder hierarchy. Notice the different flat values in the two examples.

{
    "files": [
      {
        "pattern": "generic-local/{*}",
        "target": "my/local/path/{1}",
        "flat": "true"
      }
    ]
}

{
    "files": [
      {
        "pattern": "generic-local/",
        "target": "my/local/path/",
        "flat": "false"
      }
    ]
}

Example 15

This example creates a release bundle v1 and applies "pathMapping" to the artifact paths after distributing the release bundle v1.

All occurrences of the "a1.in" file are fetched and mapped to the "froggy" repository at the edges.

1. Fetch all artifacts retrieved by the AQL query.

2. Create the release bundle v1 with the artifacts and apply the path mappings at the edges after distribution.

The "pathMapping" option is provided, allowing users to control the destination of the release bundle artifacts at the edges.

To learn more, visit the Create Release Bundle v1 Version documentation.

{
  "files": [
    {
      "aql": {
        "items.find": {
          "repo": "my-local-repo",
          "$and": [
            {
              "name": {
                "$match": "a1.in"
              }
            },
            {
              "$or": [
                {
                  "path": {
                    "$match": "."
                  }
                },
                {
                  "path": {
                    "$match": "*"
                  }
                }
              ]
            }
          ]
        }
      },
      "pathMapping": {
        "input": "my-local-repo/(.*)",
        "output": "froggy/$1"
      }
    }
  ]
}

Schema Validation

JSON schemas allow you to annotate and validate JSON files. The JFrog File Spec schema is available in the JSON Schema Store catalog and in the following link: https://github.com/jfrog/jfrog-cli/blob/v2/schema/filespec-schema.json.

Using Jetbrains IDEs (Intellij IDEA, Webstorm, Goland, etc...)?

The File Spec schema is automatically applied to the following file patterns:

**/filespecs/*.json

*filespec*.json

*.filespec

Using Visual Studio Code?

To apply the File Spec schema validation, install the JFrog VS-Code extension.

Alternatively, copy the following to your settings.json file:

settings.json

"json.schemas": [
  {
    "fileMatch": ["**/filespecs/*.json", "\*filespec\*.json", "*.filespec"],
    "url": "https://raw.githubusercontent.com/jfrog/jfrog-cli/v2/schema/filespec-schema.json"
  }
]

Overview

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

Any wildcard enclosed in parentheses in the source path can be matched with a corresponding placeholder in the target path to determine the name of the artifact once uploaded.

Examples

Example 1: Upload all files to the target repository

For each .tgz file in the source directory, create a corresponding directory with the same name in the target repository and upload it there. For example, a file named froggy.tgz should be uploaded to my-local-rep/froggy. froggy will be created in a folder in Artifactory).

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

Example 2: Upload all files sharing the same prefix to the target repository

Upload all files whose name begins with "frog" to folder frogfiles in the target repository, but append its name with the text "-up". For example, a file called froggy.tgz should be renamed froggy.tgz-up.

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

Example 3: Upload all files to corresponding directories according to extension type

Upload all files in the current directory to the my-local-repo repository and place them in directories that match their file extensions.

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

Example 4: Copy all zip files to target repository and append with an extension

Copy all zip files under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository and append the copied files' names with ".cp".

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

JFrog CLI lets you upload and download artifacts from your local file system to Artifactory, this also includes uploading symlinks (soft links).

Symlinks are stored in Artifactory as files with a zero size, with the following properties: symlink.dest - The actual path on the original filesystem to which the symlink points symlink.destsha1 - the SHA1 checksum of the value in the symlink.dest property

To upload symlinks, the jf rt upload command should be executed with the --symlinks option set to true.

When downloading symlinks stored in Artifactory, the CLI can verify that the file to which the symlink points actually exists and that it has the correct SHA1 checksum. To add this validation, you should use the --validate-symlinks option with the jf rt download command.

Overview

Execute a cURL command, using the configured Artifactory details. The command expects the cUrl client to be included in the PATH.

Note - This command supports only Artifactory REST APIs, which are accessible under https://<JFrog base URL>/artifactory/api/

Commands Params

Currently only servers configured with username and password / API key are supported.

Examples

Example 1

Execute the cUrl client, to send a GET request to the /api/build endpoint to the default Artifactory server

jf rt curl -XGET /api/build

Example 2

Execute the cUrl client, to send a GET request to the /api/build endpoint to the configured my-rt-server server ID.

jf rt curl -XGET /api/build --server-id my-rt-server

JFrog CLI offers a set of commands for managing Artifactory configuration entities.

Creating Users

This command allows creating a bulk of users. The details of the users are provided in a CSV format file. Here's the file format.

"username","password","email"
"username1","password1","john@c.com"
"username2","password1","alice@c.com"

Note: The first line in the CSV is cells' headers. It is mandatory and is used by the command to map the cell value to the users' details.

The CSV can include additional columns, with different headers, which will be ignored by the command.

Commands Params

Example

Create new users according to details defined in the path/to/users.csv file.

jf rt users-create --csv path/to/users.csv

Deleting Users

This command allows deleting a bulk of users. The command a list of usernames to delete. The list can be either provided as a comma-seperated argument, or as a CSV file, which includes one column with the usernames. Here's the CSV format.

"username"
"username1"
"username2"
"username2"

The first line in the CSV is cells' headers. It is mandatory and is used by the command to map the cell value to the users' details.

The CSV can include additional columns, with different headers, which will be ignored by the command.

Commands Params

Examples

Example 1

Delete the users according to the usernames defined in the path/to/users.csv file.

jf rt users-delete --csv path/to/users.csv

Example 2

Delete the users according to the u1, u2 and u3 usernames.

jf rt users-delete "u1,u2,u3"

Creating Groups

This command creates a new users group.

Commands Params

Example

Create a new group name reviewers .

jf rt group-create reviewers

Adding Users to Groups

This command adds a list fo existing users to a group.

Commands Params

Example

Add to group reviewers the users with the following usernames: u1, u2 and u3.

jf rt group-add-users "reviewers" "u1,u2,u3"

Deleting Groups

This command deletes a group.

Commands Params

Example

Delete the reviewers group.

jf rt group-delete "reviewers"

Managing Repositories

JFrog CLI offers a set of commands for managing Artifactory repositories. You can create, update and delete repositories. To make it easier to manage repositories, the commands which create and update the repositories accept a pre-defined configuration template file. This template file can also include variables, which can be later replaced with values, when creating or updating the repositories. The configuration template file is created using the jf rt repo-template command.

Creating or Configuration Template

This is an interactive command, which creates a configuration template file. This file should be used as an argument for the jf rt repo-create or the jf rt repo-update commands.

When using this command to create the template, you can also provide replaceable variable, instead of fixes values. Then, when the template is used to create or update repositories, values can be provided to replace the variables in the template.

Commands Params

Example

Create a configuration template, with a variable for the repository name. Then, create a repository using this template, and provide repository name to replace the variable.

$ jf rt repo-template template.json

Select the template type (press Tab for options): create
Insert the repository key > ${repo-name}
Select the repository class (press Tab for options): local
Select the repository's package type (press Tab for options): generic
You can type ":x" at any time to save and exit.
Select the next configuration key (press Tab for options): :x
[Info] Repository configuration template successfully created at template.json.
$
$ jf rt repo-create template.json --vars "repo-name=my-repo"
[Info] Creating local repository...
[Info] Done creating repository.

Creating / Updating Repositories

These two commands create a new repository and updates an existing a repository. Both commands accept as an argument a configuration template, which can be created by the jf rt repo-template command. The template also supports variables, which can be replaced with values, provided when it is used.

Commands Params

Examples

Example 1

Create a repository, using the template.json file previously generated by the repo-template command.

jf rt repo-create template.json

Example 2

Update a repository, using the template.json file previously generated by the repo-template command.

jf rt repo-update template.json

Example 3

Update a repository, using the template.json file previously generated by the repo-template command. Replace the repo-name variable inside the template with a name for the updated repository.

jf rt repo-update template.json --vars "repo-name=my-repo"

Deleting Repositories

This command permanently deletes a repository, including all of its content.

Commands Params

Example

Delete a repository from Artifactory.

jf rt repo-delete generic-local

Managing Replications

JFrog CLI offers commands creating and deleting replication jobs in Artifactory. To make it easier to create replication jobs, the commands which creates the replication job accepts a pre-defined configuration template file. This template file can also include variables, which can be later replaced with values, when creating the replication job. The configuration template file is created using the jf rt replication-template command.

Creating a Configuration Template

This command creates a configuration template file, which will be used as an argument for the jf rt replication-create command.

When using this command to create the template, you can also provide replaceable variable, instead of fixes values. Then, when the template is used to create replication jobs, values can be provided to replace the variables in the template.

Commands Params

Example

Create a configuration template, with two variables for the source and target repositories. Then, create a replication job using this template, and provide source and target repository names to replace the variables.

$ jf rt rplt template.json
Select replication job type (press Tab for options): push
Enter source repo key > ${source}
Enter target repo key > ${target}
Enter target server id (press Tab for options): my-server-id
Enter cron expression for frequency (for example: 0 0 12 * * ? will replicate daily) > 0 0 12 * * ?
You can type ":x" at any time to save and exit.
Select the next property > :x
[Info] Replication creation config template successfully created at template.json.
$
$ jf rt rplc template.json --vars "source=generic-local;target=generic-local"
[Info] Done creating replication job.

Creating Replication Jobs

This command creates a new replication job for a repository. The command accepts as an argument a configuration template, which can be created by the jf rt replication-template command. The template also supports variables, which can be replaced with values, provided when it is used.

Commands Params

Examples

Example 1

Create a replication job, using the template.json file previously generated by the replication-template command.

jf rt rplc template.json

Example 2

Update a replication job, using the template.json file previously generated by the replication-template command. Replace the source and target variables inside the template with the names of the replication source and target repositories.

jf rt rplc template.json --vars "source=my-source-repo;target=my-target-repo"

Deleting Replication jobs

This command permanently deletes a replication jobs from a repository.

Commands Params

Example

Delete a repository from Artifactory.

jf rt rpldel my-repo-name

Managing Permission Targets

JFrog CLI offers commands creating, updating and deleting permission targets in Artifactory. To make it easier to create and update permission targets, the commands which create and update the permission targets accept a pre-defined configuration template file. This template file can also include variables, which can be later replaced with values, when creating or updating the permission target. The configuration template file is created using the jf rt permission-target-template command.

Creating a Configuration Template

This command creates a configuration template file, which will be used as an argument for the jf rt permission-target-create and jf rt permission-target-update commands.

Creating / Updating Permission Targets

These commands create/update a permission target. The commands accept as an argument a configuration template, which should be created by the jf rt permission-target-template command beforehand. The template also supports variables, which can be replaced with values, provided when it is used.

Deleting Permission Targets

This command permanently deletes a permission target.

Overview

This page describes how to use the JFrog CLI to create external evidence files, which are then deployed to Artifactory. You can create evidence for:

• Artifacts

• Packages

• Builds

• Release Bundles v2

Note

• The Evidence service requires Artifactory 7.104.2 or above.

• The ability for users to attach external evidence to Artifactory, as described here, requires an Enterprise+ subscription.

• The ability to collect internal evidence generated by Artifactory requires a Pro subscription or above. Internal evidence generated by Xray requires a Pro X subscription or above.

• In the current release, an evidence file can be signed with one key only.

• The maximum size evidence file supported by Artifactory is 16MB.

For more information about the API used for deploying evidence to Artifactory, see Deploy Evidence.

Authentication

To deploy external evidence, use an access token or the web login mechanism for authentication. Basic authentication (username/password) is not supported.

Syntax

JFrog CLI uses the following syntax for creating evidence:

Artifact Evidence

jf evd create --predicate file-path --predicate-type predicate-type-uri --subject-repo-path <target-path> --subject-sha256 <digest> --key <local-private-key-path> --key-alias <public-key-name>

Package Evidence

jf evd create --predicate file-path --predicate-type predicate-type-uri --package-name <name> --package-version <version-number> --package-repo-key <repo-name> --key <local-private-key-path> --key-alias <public-key-name>

Build Evidence

jf evd create --predicate file-path --predicate-type predicate-type-uri --build-name <name> --build-number <version-number> --key <local-private-key-path> --key-alias <public-key-name>

Release Bundle v2 Evidence

jf evd create --predicate file-path --predicate-type predicate-type-uri --release-bundle <name> --release-bundle-version <version-number> --key <local-private-key-path> --key-alias <public-key-name>

Command parameters

1. --predicate file-path Mandatory field. Defines the path to a locally-stored, arbitrary json file that contains the predicates.

{
// any kind of valid json
}

1. --predicate-type predicate-type-uri Mandatory field. The type of predicate defined by the json file. Sample predicate type uris include:

 https://in-toto.io/attestation/link/v0.3
 https://in-toto.io/attestation/scai/attribute-report
 https://in-toto.io/attestation/runtime-trace/v0.1
 https://in-toto.io/attestation/test-result/v0.1
 https://in-toto.io/attestation/vulns

1. --key local-private-key-path Optional path for a private key (see Tip below). Supported key types include:

 `rsa`
 `ed25519`
 `ecdsa`

Tip

You can define the key using the JFROG_CLI_SIGNING_KEY environment variable as an alternative to using the --key command parameter. If the environment variable is not defined, the --key command is mandatory.

Note

Two key formats are supported: PEM and SSH

1. --key-alias RSA-1024 Optional case-sensitive name for the public key created from the private key. The public key is used to verify the DSSE envelope that contains the evidence.

   • If the key-alias is included, DSSE verification will fail if the same key-name is not found in Artifactory.

   • If the key-alias is not included, DSSE verification with the public key is not performed during creation.

Tip

You can define a key alias using the JFROG_CLI_KEY_ALIAS environment variable as an alternative to using the --key-alias command parameter.

Note

In the unlikely event the public key is deleted from Artifactory, it may take up to 4 hours for the Evidence service to clear the key from the cache. Evidence can still be signed with the deleted key during this time.

1. --markdown md file Optional path to a file that contains evidence formatted in markdown.

Artifact command parameters

1. --subject-repo-path target-path Mandatory field. Each evidence file must have a single subject only and must include the path. Artifacts located in local repositories aggregated inside virtual repositories are supported (evidence is added to the local path).

2. --subject-sha256 digest Optional digest (sha256) of the artifact.

• If a digest is provided, it is verified against the subject's sha256 as it appears in Artifactory.

• If a digest is not provided, the sha256 is taken from the path in Artifactory.

Package command parameters

1. --package-name name Mandatory field.

2. --package-version version-number Mandatory field.

3. --package-repo-key repo-name Mandatory field.

Build command parameters

1. --build-name name Mandatory field unless environment variables are used (see tip below).

2. --build-number version-number Mandatory field unless environment variables are used (see tip below).

Tip

You can use the FROG_CLI_BUILD_NAME and FROG_CLI_BUILD_NUMBER environment variables as an alternative to the build command parameters.

Release Bundle v2 command parameters

1. --release-bundle name Mandatory field.

2. --release-bundle-version version-number Mandatory field.

Note

When DSSE verification is successful, the following message is displayed:

Evidence successfully created and verified.

When DSSE verification is unsuccessful, the following message is displayed:

Evidence successfully created but not verified due to missing/invalid public key.

Sample commands

Artifact Evidence Sample

evd create --predicate /Users/jsmith/Downloads/code-review.json --predicate-type https://in-toto.io/attestation/vulns --subject-repo-path commons-dev-generic-local/commons/file.txt --subject-sha256 69d29925ba75eca8e67e0ad99d1132b47d599c206382049bc230f2edd2d3af30 --key /Users/jsmith/Documents/keys/private.pem --key-alias xyzey

In the sample above, the command creates a signed evidence file with a predicate type of SLSA provenance for an artifact named file.txt.

Package Evidence Sample

evd create --predicate /Users/jsmith/Downloads/code-review.json --predicate-type https://in-toto.io/attestation/vulns --package-name DockerPackage --package-version 1.0.0 --package-repo-key local-docker --key /Users/jsmith/Documents/keys/private.pem --key-alias xyzey

Build Evidence Sample

evd create --predicate /Users/jsmith/Downloads/code-review.json --predicate-type https://in-toto.io/attestation/vulns --build-name Commons-Build --build-number 1.0.0 --key /Users/jsmith/Documents/keys/private.pem --key-alias xyzey

Release Bundle v2 Evidence Sample

evd create --predicate /Users/jsmith/Downloads/code-review.json --predicate-type https://in-toto.io/attestation/vulns --release-bundle bundledemo --release-bundle-version (mandatory) 1.0.0 --key /Users/jsmith/Documents/keys/private.pem --key-alias xyzey

Authentication

When used with Xray, JFrog CLI offers several means of authentication: JFrog CLI does not support accessing Xray without authentication.

Authenticating with Username and Password

To authenticate yourself using your Xray login credentials, either configure your credentials once using the_jf c add_command or provide the following option to each command.

Authenticating with an Access Token

To authenticate yourself using an Xray Access Token, either configure your Access Token once using the _jf c add_command or provide the following option to each command.

To use the CLI, install it on your local machine, or download its executable, place it anywhere in your file system and add its location to your PATH environment variable.

Environment Variables

The jf options command displays all the supported environment variables.

JFrog CLI makes use of the following environment variables:

JFrog CLI supports using an HTTP/S proxy. All you need to do is set HTTP_PROXY or HTTPS_PROXY environment variable with the proxy URL.

HTTP_PROXY, HTTPS_PROXY and NO_PROXY are the industry standards for proxy usages.

Welcome to the JFrog Applications Doc Hub

Shift Left with JFrog Security

Web Login to the JFrog Platform

You can use the jf login command to authenticate with the JFrog Platform through the web browser. This command is solely interactive, meaning it does not receive any options and cannot be used in a CI server.

Creating Access Tokens

This command allows creating Access Tokens for users in the JFrog Platform. By default, a user-scoped token will be created. Administrators may provide the scope explicitly with '--scope', or implicitly with '--groups', '--grant-admin'.

Commands Params

Examples

Example 1

Create an access token for the user in the default server configured by the jf c add command:

jf atc

Example 2

Create an access token for the user with the toad username:

jf atc toad

Adding and Editing Configured Servers

The config add and config edit commands are used to add and edit JFrog Platform server configuration, stored in JFrog CLI's configuration storage. These configured servers can be used by the other commands. The configured servers' details can be overridden per command by passing in alternative values for the URL and login credentials. The values configured are saved in file under the JFrog CLI home directory.

Removing Configured Servers

The config remove command is used to remove JFrog Platform server configuration, stored in JFrog CLI's configuration storage.

Showing the Configured Servers

The config show command shows the stored configuration. You may show a specific server's configuration by sending its ID as an argument to the command.

Setting a Server as Default

The config use command sets a configured server as default. The following commands will use this server.

Exporting and Importing Configuration

The config export command generates a token, which stores the server configuration. This token can be used by the config import command, to import the configuration stored in the token, and save it in JFrog CLI's configuration storage.

Export

Import

Sensitive Data Encryption

File-Based Encryption

Starting from version 1.37.0, JFrog CLI introduces support for encrypting sensitive data stored in its configuration using an encryption key stored in a file. Follow these steps to enable encryption:

1. Generate a random 32-character master key. Ensure that the key size is exactly 32 characters. For example: f84hc22dQfhe9f8ydFwfsdn48!wejh8A

2. Create a file named security.yaml under ~/.jfrog/security.

   If you've customized the default JFrog CLI home directory by setting the JFROG_CLI_HOME_DIR environment variable, create the security/security.yaml file under the configured home directory.

3. Add the generated master key to the security.yaml file:

   Copy

   version: 1
   masterKey: "your master key"

4. Ensure that the security.yaml file has only read permissions for the user running JFrog CLI.

The configuration will be encrypted the next time JFrog CLI accesses the config. If you have existing configurations stored before creating the file, you'll need to reconfigure the servers stored in the config.

Warning: When upgrading JFrog CLI from a version prior to 1.37.0 to version 1.37.0 or above, automatic changes are made to the content of the ~/.jfrog directory to support the new functionality introduced. Before making these changes, the content of the ~/.jfrog directory is backed up inside the ~/.jfrog/backup directory. After enabling sensitive data encryption, it is recommended to remove the backup directory to ensure no sensitive data is left unencrypted.

Environment Variable-Based Encryption

Starting from version 2.36.0, JFrog CLI also supports encrypting sensitive data in its configuration using an encryption key stored in an environment variable. To enable encryption, follow these steps:

1. Generate a random 32-character master key. Ensure that the key size is exactly 32 characters. For example: f84hc22dQfhe9f8ydFwfsdn48!wejh8A

2. Store the key in an environment variable named JFROG_CLI_ENCRYPTION_KEY.

The configuration will be encrypted the next time JFrog CLI attempts to access the config. If you have configurations already stored before setting the environment variable, you'll need to reconfigure the servers stored in the config.

ONLY ACTIVE JFROG CUSTOMERS ARE AUTHORIZED TO USE THE JFROG AI ASSISTANT. ALL OTHER USES ARE PROHIBITED.

Overview

The JFrog CLI AI Command Assistant streamlines your workflow by turning natural language inputs into JFrog CLI commands.

Simply describe your desired actions, and the assistant generates commands with all necessary parameters, whether you're uploading artifacts, managing repositories, scanning your code, or performing other actions using the JFrog CLI.

Each query is treated individually, and while the interface allows you to refine requests, it doesn’t maintain a chat history.

This tool helps users access the full power of JFrog CLI without needing to remember specific syntax, ensuring efficiency and accuracy.

How to Use the JFrog CLI AI Command Assistant

To use the JFrog CLI AI Command Assistant, follow these simple steps:

1. Open your terminal

Ensure that you are in a terminal session where JFrog CLI is installed and configured.

2. Supported Version Validation

This feature is available starting from CLI version 2.69 and above. To validate your version, run:

jf --version

3. Enter the command

Type the following command to initiate the AI assistant:

jf how

4. Provide your request

After entering the command, you will see a prompt:

Your request:

Describe in natural language what you would like the JFrog CLI to do. The AI assistant will generate the exact CLI command needed.

For example, you might type:

Your request: How to upload all files in the 'build' directory to the 'my-repo' repository?

5. Receive the generated command

The AI assistant will process your request and output the corresponding JFrog CLI command, including all necessary parameters. For the example above, it will generate:

jf rt u build/ my-repo/

6. Execute or modify

You can now copy the generated command and run it in your terminal.

If needed, you can refine your request and try again.

FAQ

Some of the Artifactory commands make use of the following environment variable:

Note

Scanning Files on the Local File System

This jf scan command scans files on the local file system with Xray.

Note

This command requires:

• Version 3.29.0 or above of Xray

• Version 2.1.0 or above of JFrog CLI

Commands Params

Example 1

Scans all the files located at the path/ti/files/ file-system directory using the watch1 watch defined in Xray.

Example 2

Scans all the files located at the path/ti/files/ file-system directory using the watch1 and watch2 Watches defined in Xray.

Example 3

Scans all the zip files located at the path/ti/files/ file-system directory using the watch1 and watch2 Watches defined in Xray.

Example 4

Scans all the tgz files located at the path/ti/files/ file-system directory using the policies defined for project-1.

Example 5

Scans all the tgz files located in the current directory using the policies defined for the libs-local/release-artifacts/ path in Artifactory.

Example 6

Scans all the tgz files located at the current directory. Show all known vulnerabilities, regardless of the policies defined in Xray.

Scanning Docker Containers on the Local File System

This jf docker scan command scans docker containers located on the local file-system using the docker client and JFrog Xray. The containers don't need to be deployed to Artifactory or any other container registry before it can be scanned.

Note

This command requires:

• Version 3.40.0 or above of Xray

• Version 2.11.0 or above of JFrog CLI

Commands Params

Example 1

Scan the local reg1/repo1/img1:1.0.0 container and show all known vulnerabilities, regardless of the policies defined in Xray.

Example 2

Scan the local reg1/repo1/img1:1.0.0 container and show all violations according to the policy associated with my-project JFrog project.

Example 3

Scan the local reg1/repo1/img1:1.0.0 container and show all violations according to the policy associated with my-watch Xray Watch.

Example 4

Scan the local reg1/repo1/img1:1.0.0 container and show all violations according to the policy associated with the releases-local/app1/ path in Artifactory.

Scanning Image Tarballs on the Local File System

The ‘scan’ command can be used to scan tarballs of Docker and OCI images on the local file system.

It requires saving the image on the file system as an uncompressed tarball using a compliant tool, and then scanning it with the ‘jf s’ command. The image must be saved to the file system uncompressed, in a <name>.tar file name.

Note

This command requires:

• Version 3.61.5 or above of Xray.

• Version 2.14.0 or above of JFrog CLI.

Docker Client

Use Docker client ‘docker save’ command to save the image to the file system for scanning.

Example:

Skopeo

Use Skopeo CLI to save an image to the file system. Output image can be either OCI or Docker format.

Example:

Podman

Use Podman CLI to save an image to the file system. Output image can be either OCI or Docker format.

Example:

Kaniko

Use Kaniko ‘--tarPath’ flag to save built images to the file system, and later scan them with JFrog CLI. The example below is running Kaniko in Docker.

Example:

Overview

JFrog Curation defends your software supply chain, enabling early blocking of malicious or risky open-source packages before they even enter. Seamlessly identify harmful, vulnerable, or risky packages, ensuring increased security, compliance, and developer productivity.

The 'curation-audit' is a JFrog CLI command designed for developers to scan their projects and identify third-party dependencies that violate the restrictions set by the Curation service. This command provides detailed insights into the specific package policies that are being violated, leading to their blockage by the Curation service. Additionally, when feasible, 'curation-audit' may suggest alternative versions of the packages that comply with the Curation policies.

Moreover, curation-audit supports waiver requests for eligible violations. If configured in the policy, developers can select the blocked package and request a waiver from the policy owner.

Supported package managers & build systems

Curation-audit command supported package managers and build systems:

• Npm (npm)

• Maven (mvn) - Requires xray 3.92 and above, and Artifactory 7.82 and above

• Pip (pip) - Requires xray 3.92 and above, and Artifactory 7.82 and above

• Go (go) - Requires xray 3.92 and above, and Artifactory 7.87 and above

Commands

Audit your Project with JFrog CLI curation-audit command

Setup:

Prerequisites:

1. Connect JFrog CLI to JFrog Platform

   Connect the JFrog CLI to your JFrog Platform instance by running the following command:

   • It should present Artifactory server just added (with default true)

2. Configure JFrog CLI for Project Ensure your project is configured in the JFrog CLI with the repository you would like to resolve dependencies from. Here are details for each package manager:

   • NPM:
   • MAVEN:
   • PIP:
   • GO:

Commands Params

Example 1

Curation-Audit the project in the current directory. Displays all known packages that were blocked by Curation Policies.

Example 2

Curation-Audit the projects according to the specific paths defined in the "working-dirs" option. Displays all known packages that were blocked by Curation Policies for all projects. The data is displayed in separate tables.

Example 3

Curation-Audit the project in the current directory using 5 threads to check the packages Curation status in parallel. Displays all known packages blocked by Curation Policies.

Example 4

Curation-Audit Waiver Request Process: The developer specifies the required row(s) from the table for the blocked policies. They then add a description and submit the request. A summary table is presented at the end of the process.

Overview

Syntax

When used with JFrog Distribution, JFrog CLI uses the following syntax:

Managing Access Keys

Commands

The following sections describe the commands available in the JFrog CLI for use with JFrog Distribution.

Creating or updating an unsigned Release Bundle

This commands creates and updates an unsigned Release Bundle on JFrog Distribution.

Note

Commands Params

Example 1

Create a release bundle with name myApp and version 1.0.0. The release bundle will include the files defined in the File Spec specified by the --spec option.

Example 2

Create a release bundle with name myApp and version 1.0.0. The release bundle will include the files defined in the File Spec specified by the --spec option. GPG sign the release bundle after it is created.

Example 3

Update the release bundle with name myApp and version 1.0.0. The release bundle will include the files defined in the File Spec specified by the --spec option.

Example 4

Update the release bundle with name myApp and version 1.0.0. The release bundle will include all the zip files inside the zip folder, located at the root of the my-local-repo repository.

Example 5

Update the release bundle with name myApp and version 1.0.0. The release bundle will include all the zip files inside the zip folder, located at the root of the my-local-repo repository. The files will be distributed on the Edge Node to the target-zips folder, under the root of the my-target-repo repository.

Example 6

Example 7

This example creates a release bundle and applies "pathMapping" to the artifact paths after distributing the release bundle.

All occurrences of the "a1.in" file are fetched and mapped to the "froggy" repository at the edges.

1. Fetch all artifacts retrieved by the AQL query.

2. Create the release bundle with the artifacts and apply the path mappings at the edges after distribution.

The "pathMapping" option is provided, allowing users to control the destination of the release bundle artifacts at the edges.

Note: The "target" option is designed to work for most use cases. The "pathMapping" option is intended for specific use cases, such as including a list.manifest.json file inside the release bundle.

In that scenario, the distribution server dynamically includes all the manifest.json and their layers and assigns the given path mapping, whereas "target" doesn't achieve this.

Spec file content:

Signing an Existing Release Bundle

This command GPG signs an existing Release Bundle on JFrog Distribution.

Note

Commands Params

Example

GPG sign the release bundle with name myApp and version 1.0.0.

Distributing a Release Bundle

This command distributes a release bundle to the Edge Nodes.

Note

Commands Params

Example 1

Distribute the release bundle with name myApp and version 1.0.0. Use the distribution rules defined in the specified file.

Deleting a Release Bundle

This command deletes a Release Bundle from the Edge Nodes and optionally from Distribution as well.

Note

Commands Params

Example 1

Delete the release bundle with name myApp and version 1.0.0 from the Edge Nodes only, according to the definition in the distribution rules file.

Example 2

Delete the release bundle with name myApp and version 1.0.0 from the Edge Nodes, according to the definition in the distribution rules file. The release bundle will also be deleted from the Distribution service itself.

The offline-update command downloads updates to Xray's vulnerabilities database. The Xray UI allows building the command structure for you.

Uploading Files

This command is used to upload files to Artifactory.

Usage

jf rt u [command options] <Source path> <Target path> jf rt u --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Upload a file called froggy.tgz to the root of the my-local-repo repository.

Example 2

Collect all the zip files located under the build directory (including subdirectories), and upload them to the my-local-repo repository, under the zipFiles folder, while maintaining the original names of the files.

Example 3

Collect all the zip files located under the build directory (including subdirectories), and upload them to the my-local-repo repository, under the zipFiles folder, while maintaining the original names of the files. Also delete all files in the my-local-repo repository, under the zipFiles folder, except for the files which were uploaded by this command.

Example 4

Collect all files located under the build directory (including subdirectories), and upload them to the my-release-local repository, under the files folder, while maintaining the original names of the artifacts. Exclude (do not upload) files, which include install as part of their path, and have the pack extension. This example uses a wildcard pattern. See Example 5, which uses regular expressions instead.

Example 5

Collect all files located under the build directory (including subdirectories), and upload them to the my-release-local repository, under the files folder, while maintaining the original names of the artifacts. Exclude (do not upload) files, which include install as part of their path, and have the pack extension. This example uses a regular expression. See Example 4, which uses a wildcard pattern instead.

Example 6

Collect all files located under the build directory and match the /*.zip ANT pattern, and upload them to the my-release-local repository, under the files folder, while maintaining the original names of the artifacts.

Example 7

Package all files located under the build directory (including subdirectories) into a zip archive named archive.zip , and upload the archive to the my-local-repo repository,

Downloading Files

This command is used to download files from Artifactory.

Download from Remote Repositories: By default, the command downloads only the files that are cached on the current Artifactory instance. It does not retrieve files from remote Artifactory instances accessed via remote or virtual repositories. To enable the command to download files from remote Artifactory instances (proxied through remote repositories), set the JFROG_CLI_TRANSITIVE_DOWNLOAD environment variable to true. This feature is available in Artifactory version 7.17 or later. Note that remote downloads are supported only for remote repositories that proxy other Artifactory instances. Downloads from remote repositories that proxy non-Artifactory repositories are not supported. IMPORTANT: Enabling the JFROG_CLI_TRANSITIVE_DOWNLOAD environment variable may increase the load on the remote Artifactory instance. It is advisable to use this setting cautiously.

Usage

jf rt dl [command options] <Source path> [Target path] jf rt dl --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Download an artifact called cool-froggy.zip located at the root of the my-local-repo repository to the current directory.

Example 2

Download all artifacts located under the all-my-frogs directory in the my-local-repo repository to the all-my-frogs folder under the current directory.

Example 3

Download all artifacts located in the **my-local-repo **repository with a jar extension to the all-my-frogs folder under the current directory.

Example 4

Download the latest file uploaded to the all-my-frogs folder in the my-local-repo repository.

Copying Files

This command is used to copy files in Artifactory

Usage

jf rt cp [command options] <Source path> <Target path> jf rt cp --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Copy all artifacts located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository.

Example 2

Copy all zip files located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository.

Example 3

Copy all artifacts located under /rabbit in the source-frog-repo repository and with property "Version=1.0" into the same path in the target-frog-repo repository.

Example 4

Copy all artifacts located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository without maintaining the original subdirectory hierarchy.

Moving Files

This command is used to move files in Artifactory

Usage

jf rt mv [command options] <Source path> <Target path> jf rt mv --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Move all artifacts located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository.

Example 2

Move all zip files located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository.

Example 3

Move all artifacts located under /rabbit in the source-frog-repo repository and with property "Version=1.0" into the same path in the target-frog-repo repository .

Example 4

Move all artifacts located under /rabbit in the source-frog-repo repository into the same path in the target-frog-repo repository without maintaining the original subdirectory hierarchy.

Deleting Files

This command is used to delete files in Artifactory

Usage

jf rt del [command options] <Delete path> jf rt del --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Delete all artifacts located under /rabbit in the frog-repo repository.

Example 2

Delete all zip files located under /rabbit in the frog-repo repository.

Searching Files

This command is used to search and display files in Artifactory.

Usage

jf rt s [command options] <Search path> jf rt s --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Display a list of all artifacts located under /rabbit in the frog-repo repository.

Example 2

Display a list of all zip files located under /rabbit in the frog-repo repository.

Example 3

Display a list of the files under example-repo-local with the following fields: path, actual_md5, modified_b, updated and depth.

Setting Properties on Files

This command is used for setting properties on existing files in Artifactory.

Usage

jf rt sp [command options] <Files pattern> <Files properties> jf rt sp <artifact properties> --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Set the properties on all the zip files in the generic-local repository. The command will set the property "a" with "1" value and the property "b" with two values: "2" and "3".

Example 2

The command will set the property "a" with "1" value and the property "b" with two values: "2" and "3" on all files found by the File Spec my-spec.

Example 3

Set the properties on all the jar files in the maven-local repository. The command will set the property "version" with "1.0.0" value and the property "release" with "stable" value.

Example 4

The command will set the property "environment" with "production" value and the property "team" with "devops" value on all files found by the File Spec prod-spec.

Example 5

Set the properties on all the tar.gz files in the devops-local repository. The command will set the property "build" with "102" value and the property "branch" with "main" value.

Deleting Properties from Files

This command is used for deleting properties from existing files in Artifactory.

Usage

jf rt delp [command options] <Files pattern> <Properties list> jf rt delp <artifact properties> --spec=<File Spec path> [command options]

Commands Params

Examples

Example 1

Remove the properties version and release from all the jar files in the maven-local repository.

Example 2

Delete the properties build and branch from all tar.gz files in the devops-local repo.

Example 3

Remove the properties status, phase and stage from all deb files that start with DEV in the debian-repository.

Example 4

Delete the environment property from /tests/local/block.rpm in the centos-repo.

Example 5

Remove the properties component, layer and level from files in the docker-hub repository.

The jf audit command allows scanning your source code dependencies to find security vulnerabilities and licenses violations, with the ability to scan against your Xray policies. The command builds a deep dependencies graph for your project, scans it with Xray, and displays the results. It uses the package manager used by the project to build the dependencies graph. Currently, the following package managers are supported.

• Maven (mvn) - Version 3.1.0 or above of Maven is supported.

• Gradle (gradle)

• Npm (npm)

• Pnpm (pnpm)

• Yarn (yarn)

• Pip (pip)

• Pipenv (pipenv)

• Poetry (poetry)

• Go Modules (go)

• NuGet (nuget)

• .NET Core CLI (dotnet)

• CocoaPods (pod)

• SwiftPM (swift)

• Conan (C++)

The command will detect the package manager used by the project automatically. It requires version 3.29.0 or above of Xray and also version 2.13.0 or above of JFrog CLI.

Advanced Scans

• Vulnerability Contextual Analysis: This feature uses the code context to eliminate false positive reports on vulnerable dependencies that are not applicable to the code. Vulnerability Contextual Analysis is currently supported for Python, Go and JavaScript code.

• Secrets Detection: Detect any secrets left exposed inside the code. to stop any accidental leak of internal tokens or credentials.

• Infrastructure as Code scans (IaC): Scan Infrastructure as Code (Terraform) files for early detection of cloud and infrastructure misconfigurations.

Note

• The jf audit command does not extract the internal content of the scanned dependencies. This means that if a package includes other vulnerable components bundled inside the binary, they may not be shown as part of the results. This is contrary to the jf scan command, which drills down into the package content.

• To generate the dependency tree for scanning purposes, the system will execute an install command on the project if it hasn't been executed previously.

Commands Params

Output Example

Example 1

Audit the project at the current directory. Show all known vulnerabilities, regardless of the policies defined in Xray.

Example 2

Audit the project at the current directory. Show all known vulnerabilities, regardless of the policies defined in Xray. Show only maven and npm vulnerabilities.

Example 3

Audit the project at the current directory using a watch named watch1 watch defined in Xray.

Example 4

Audit the project at the current directory using watch1 and _watch2_ defined in Xray.

Example 5

Audit the project at the current directory using the policies defined for project-1.

Example 6

Audit the project at the current directory using the policies defined for the libs-local/release-artifacts/ path in Artifactory.

Example 7

Audit the project in the current directory, excluding all files inside the node_modules directory and files with the to_exclude suffix.

Scanning Published Builds

Commands Params

Example

Scan build number 18, corresponding to the following build name: 'my-build-name'.

The sbom enrichment command takes an exported SBOM file (Only CycloneDX format) in XML/JSON format and enriches your file with package vulnerabilities found by XRAY.

This jf sbom enrich <file_path> command enriches a file that is found on file_path.

Note

This command requires:

• Version 3.101.3 or above of Xray

• Version 2.60.0 or above of JFrog CLI

Commands Params

Example 1

Enriches an XML file

Example 2

Enriches a JSON file

Overview

Collecting Build-Info

Build-info is collected by adding the --build-name and --build-number options to different CLI commands. The CLI commands can be run several times and cumulatively collect build-info for the specified build name and number until it is published to Artifactory. For example, running the jf rt download command several times with the same build name and number will accumulate each downloaded file in the corresponding build-info.

Collecting Dependencies

Dependencies are collected by adding the --build-name and --build-number options to the jf rt download command.

For example, the following command downloads the cool-froggy.zip file found in repository my-local-repo, but it also specifies this file as a dependency in build my-build-name with build number 18:

Collecting Build Artifacts

Build artifacts are collected by adding the --build-name and --build-number options to the jf rt upload command.

For example, the following command specifies that file froggy.tgz uploaded to repository my-local-repo is a build artifact of build my-build-name with build number 18:

Collecting Environment Variables

This command is used to collect environment variables and attach them to a build.

Environment variables are collected using the build-collect-env (bce) command.

Usage

jf rt bce <build name> <build number>

Commands Params

The following table lists the command arguments and flags:

Examples

Example 1

The following command collects all currently known environment variables, and attaches them to the build-info for build my-build-name with build number 18:

Example 2

Collect environment variables for build name: frogger-build and build number: 17

Collecting Information from Git

The build-add-git (bag) command collects the Git revision and URL from the local .git directory and adds it to the build-info. It can also collect the list of tracked project issues (for example, issues stored in JIRA or other bug tracking systems) and add them to the build-info. The issues are collected by reading the git commit messages from the local git log. Each commit message is matched against a pre-configured regular expression, which retrieves the issue ID and issue summary. The information required for collecting the issues is retrieved from a yaml configuration file provided to the command.

Usage

jf rt bag [command options] <build name> <build number> [Path To .git]

Commands Params

The following table lists the command arguments and flags:

Configuration file properties

Example

This is the configuration file structure.

Adding Files as Build Dependencies

The download command, as well as other commands which download dependencies from Artifactory accept the --build-name and --build-number command options. Adding these options records the downloaded files as build dependencies. In some cases however, it is necessary to add a file, which has been downloaded by another tool, to a build. Use the build-add-dependencies command to this.

By default, the command collects the files from the local file system. If you'd like the files to be collected from Artifactory however, add the --from-rt option to the command.

Usage

jf rt bad [command options] <build name> <build number> <pattern> jf rt bad --spec=<File Spec path> [command options] <build name> <build number>

Commands Params

Examples

Example 1

Add all files located under the path/to/build/dependencies/dir directory as dependencies of a build. The build name is my-build-name and the build number is 7. The build-info is only updated locally. To publish the build-info to Artifactory use the jf rt build-publish command.

Example 2

Add all files located in the m-local-repo Artifactory repository, under the dependencies folder, as dependencies of a build. The build name is my-build-name and the build number is 7. The build-info is only updated locally. To publish the build-info to Artifactory use the jf rt build-publish command.

Example 3

Add all files located under the path/to/build/dependencies/dir directory as dependencies of a build. The build name is my-build-name, the build number is 7 and module is m1. The build-info is only updated locally. To publish the build-info to Artifactory use the jf rt build-publish command.

Publishing Build-Info

This command is used to publish build info to Artifactory. To publish the accumulated build-info for a build to Artifactory, use the build-publish command. For example, the following command publishes all the build-info collected for build my-build-name with build number 18:

Usage

jf rt bp [command options] <build name> <build number>

Commands Params

Example

Publishes to Artifactory all the build-info collected for build my-build-name with build number 18

Aggregating Published Builds

The build-info, which is collected and published to Artifactory by the jf rt build-publish command, can include multiple modules. Each module in the build-info represents a package, which is the result of a single build step, or in other words, a JFrog CLI command execution. For example, the following command adds a module named m1 to a build named my-build with 1 as the build number:

The following command, adds a second module, named m2 to the same build:

You now publish the generated build-info to Artifactory using the following command:

Now that you have your build-info published to Artifactory, you can perform actions on the entire build. For example, you can download, copy, move or delete all or some of the artifacts of a build. Here's how you do this.

In some cases though, your build is composed of multiple build steps, which are running on multiple different machines or spread across different time periods. How do you aggregate those build steps, or in other words, aggregate those command executions, into one build-info?

The way to do this, is to create a separate build-info for every section of the build, and publish it independently to Artifactory. Once all the build-info instances are published, you can create a new build-info, which references all the previously published build-info instances. The new build-info can be viewed as a "master" build-info, which references other build-info instances.

So the next question is - how can this reference between the two build-instances be created?

The way to do this is by using the build-append command. Running this command on an unpublished build-info, adds a reference to a different build-info, which has already been published to Artifactory. This reference is represented by a new module in the new build-info. The ID of this module will have the following format: **<referenced build name>/<referenced build number>.

Now, when downloading the artifacts of the "master" build, you'll actually be downloading the artifacts of all of its referenced builds. The examples below demonstrates this,

Usage

jf rt ba <build name> <build number> <build name to append> <build number to append>

Commands Params

Requirements

Artifactory version 7.25.4 and above.

Example

This script illustrates the process of creating two build-info instances, publishing both to Artifactory, and subsequently generating a third build-info that consolidates the published instances before publishing it to Artifactory.

Promoting a Build

Usage

jf rt bpr [command options] <build name> <build number> <target repository>

Commands Params

Example

This example involves moving the artifacts associated with the published build-info, identified by the build name 'my-build-name' and build number '18', from their existing Artifactory repository to a new Artifactory repository called 'target-repository'.

Cleaning up the Build

Build-info is accumulated by the CLI according to the commands you apply until you publish the build-info to Artifactory. If, for any reason, you wish to "reset" the build-info and cleanup (i.e. delete) any information accumulated so far, you can use the build-clean (bc) command.

Usage

jf rt bc <build name> <build number>

Commands Params

The following table lists the command arguments and flags:

Example

The following command cleans up any build-info collected for build my-build-name with build number 18:

Discarding Old Builds from Artifactory

Usage

jf rt bdi [command options] <build name>

Commands Params

The following table lists the command arguments and flags:

Examples

Example 1

Discard the oldest build numbers of build my-build-name from Artifactory, leaving only the 10 most recent builds.

Example 2

Discard the oldest build numbers of build my-build-name from Artifactory, leaving only builds published during the last 7 days.

Example 3

Discard the oldest build numbers of build my-build-name from Artifactory, leaving only builds published during the last 7 days. b20 and b21 will not be discarded.

Overview

The transfer-files command allows transferring (copying) all the files stored in one Artifactory instance to a different Artifactory instance. The command allows transferring the files stored in a single or multiple repositories. The command expects the relevant repository to already exist on the target instance and have the same name and type as the repositories on the source.

Limitations

1. Artifacts in remote repositories caches are not transferred.

2. The files transfer process allows transferring files that were created or modified on the source instance after the process started. However, files that were deleted on the source instance after the process started, are not deleted on the target instance by the process.

3. The files transfer process allows transferring files that were created or modified on the source instance after the process started. The custom properties of those files are also updated on the target instance. However, if only the custom properties of those file were modified on the source, but not the files' content, the properties are not modified on the target instance by the process.

4. The source and target repositories should have the same name and type.

5. Since the file are pushed from the source to the target instance, the source instance must have network connection to the target.

Before You Begin

1. Ensure that you can log in to the UI of both the source and target instances with users that have admin permissions and that you have the connection details (including credentials) to both instances.

2. Ensure that all the repositories on source Artifactory instance which files you'd like to transfer, also exist on the target instance, and have the same name and type on both instances.

3. Ensure that JFrog CLI is installed on a machine that has network access to both the source and target instances.

Running the Transfer Process

Step 1 - Set Up the Source Instance for Files Transfer

To set up the source instance for files transfer, you must install the data-transfer user plugin in the primary node of the source instance. This section guides you through the installation steps.

2. Configure the connection details of the source Artifactory instance with your admin credentials by running the following command from the terminal.
3. Ensure that the JFROG_HOME environment variable is set and holds the value of JFrog installation directory. It usually points to the /opt/jfrog directory. In case the variable isn't set, set its value to point to the correct directory as described in the JFrog Product Directory Structure article.

Step 2 - Push the Files from the Source to the Target Instance

Run the following command to start pushing the files from all the repositories in source instance to the target instance.

This command may take a few days to push all the files, depending on your system size and your network speed. While the command is running, It displays the transfer progress visually inside the terminal.

If you're running the command in the background, you use the following command to view the transfer progress.

In case you do not wish to transfer the files from all repositories, or wish to run the transfer in phases, you can use the --include-repos and --exclude-repos command options. Run the following command to see the usage of these options.

You can stop the transfer process by hitting on CTRL+C if the process is running in the foreground, or by running the following command, if you're running the process in the background.

The process will continue from the point it stopped when you re-run the command.

A path to an errors summary file will be printed at the end of the run, referring to a generated CSV file. Each line on the summary CSV represents an error of a file that failed to be transferred. On subsequent executions of the jf rt transfer-files command, JFrog CLI will attempt to transfer these files again.

Once the jf rt transfer-files command finishes transferring the files, you can run it again to transfer files which were created or modified during the transfer. You can run the command as many times as needed. Subsequent executions of the command will also attempt to transfer files failed to be transferred during previous executions of the command.

Note:

Installing the data-transfer User Plugin on the Source Machine Manually

To install the data-transfer user plugin on the source machine manually, follow these steps.

1. Download the following two files from a machine that has internet access. Download data-transfer.jar from https://releases.jfrog.io/artifactory/jfrog-releases/data-transfer/[RELEASE]/lib/data-transfer.jar and dataTransfer.groovy from https://releases.jfrog.io/artifactory/jfrog-releases/data-transfer/[RELEASE]/dataTransfer.groovy

2. Create a new directory on the primary node machine of the source instance and place the two files you downloaded inside this directory.

3. Install the data-transfer user plugin by running the following command from the terminal. Replace the [plugin files dir] token with the full path to the directory which includes the plugin files you downloaded.

Installing JFrog CLI on the Source Instance Machine

Install JFrog CLI on your source instance by using one of the [#JFrog CLI Installers]. For example:

Note

If the source instance is running as a docker container, and you're not able to install JFrog CLI while inside the container, follow these steps.

1. Connect to the host machine through the terminal.

2. Download the JFrog CLI executable into the correct directory by running this command:

   curl -fL https://getcli.jfrog.io/v2-jf | sh

3. Copy the JFrog CLI executable you've just downloaded into the container, by running the following docker command. Make sure to replace [the container name] with the name of the container.

   docker cp jf [the container name]:/usr/bin/jf

4. Connect to the container and run the following command to ensure JFrog CLI is installed:

   jf -v

How Does Files Transfer Work?

Files Transfer Phases

The jf rt transfer-files command pushes the files from the source instance to the target instance as follows:

• The files are pushed for each repository, one by one in sequence.

• For each repository, the process includes the following three phases:

  • Phase 1 pushes all the files in the repository to the target.

  • Phase 2 pushes files which have been created or modified after phase 1 started running (diffs).

  • Phase 3 attempts to push files which failed to be transferred in earlier phases (Phase 1 or Phase 2) or in previous executions of the command.

• If Phase 1 finished running for a specific repository, and you run the jf rt transfer-files command again, only Phase 2 and Phase 3 will be triggered. You can run the jf rt transfer-files as many times as needed, till you are ready to move your traffic to the target instance permanently. In any subsequent run of the command, Phase 2 will transfer the newly created and modified files and Phase 3 will retry transferring files which failed to be transferred in previous phases and also in previous runs of the command.

Using Replication

To help reduce the time it takes for Phase 2 to run, you may configure Event Based Push Replication for some or all of the local repositories on the source instance. With Replication configured, when files are created or updated on the source repository, they are immediately replicated to the corresponding repository on the target instance. The replication can be configured at any time. Before, during or after the files transfer process.

Files Transfer State

You can run the jf rt transfer-files command multiple times. This is needed to allow transferring files which have been created or updated after previous command executions. To achieve this, JFrog CLI stores the current state of the files transfer process in a directory named transfer located under the JFrog CLI home directory. You can usually find this directory at this location ~/.jfrog/transfer.

JFrog CLI uses the state stored in this directory to avoid repeating transfer actions performed in previous executions of the command. For example, once Phase 1 is completed for a specific repository, subsequent executions of the command will skip Phase 1 and run Phase 2 and Phase 3 only.

In case you'd like to ignore the stored state, and restart the files transfer from scratch, you can add the --ignore-state option to the jf rt transfer-files command.

Installing JFrog CLI on a Machine with Network Access to the Source and Target Machines

It is recommended to run the transfer-files command from a machine that has network access to the source Artifactory URL. This allows spreading the transfer load on all the Artifactory cluster nodes. This machine should also have network access to the target Artifactory URL.

Follows these steps to installing JFrog CLI on that machine.

1. Install JFrog CLI by using one of the [#JFrog CLI Installers]. For example:
2. If your source instance is accessible only through an HTTP/HTTPS proxy, set the proxy environment variable as described [#here].

3. Configure the connection details of the source Artifactory instance with your admin credentials. Run the following command and follow the instructions.
4. Configure the connection details of the target Artifactory instance as follows.

Controlling the File Transfer Speed

The jf rt transfer-files command pushes the binaries from the source instance to the target instance. This transfer can take days, depending on the size of the total data transferred, the network bandwidth between the source and the target instance, and additional factors.

Since the process is expected to run while the source instance is still being used, monitor the instance to ensure that the transfer does not add too much load to it. Also, you might decide to increase the load for faster a transfer rate, while you monitor the transfer. This section describes how to control the file transfer speed.

By default, the jf rt transfer-files command uses 8 working threads to push files from the source instance to the target instance. Reducing this value will cause slower transfer speed and lower load on the source instance, and increasing it will do the opposite. We therefore recommend increasing it gradually. This value can be changed while the jf rt transfer-files command is running. There's no need to stop the process to change the total of working threads. The new value set will be cached by JFrog CLI and also used for subsequent runs from the same machine. To set the value, simply run the following interactive command from a new terminal window on the same machine which runs the jf rt transfer-files command.

Build-info repositories

When transferring files in build-info repositories, JFrog CLI limits the total of working threads to 8. This is done in order to limit the load on the target instance while transferring build-info.

Routing the Traffic from the Source to the Target Through an HTTPS Proxy

The jf rt transfer-files command pushes the files directly from the source to the target instance over the network. In case the traffic from the source instance needs to be routed through an HTTPS proxy, follow these steps.

2. When running the jf rt transfer-files command, add the --proxy-key option to the command, with Proxy Key you configured in the UI as the option value. For example, if the Proxy Key you configured is my-proxy-key, run the command as follows:

Overview

Note

Syntax

When used with JFrog Release Lifecycle Management, JFrog CLI uses the following syntax:

Create a Release Bundle v2

• Published build info:

  <build-number> is optional; the latest build will be used if empty. includeDeps is optional, false by default. project is optional; the default project will be used if empty.

• Existing Release Bundles:

  project is optional; the default project will be used if empty.

• A pattern of artifacts in Artifactory:

  Only pattern is mandatory. recursive is true by default.

• AQL query:

  Only a single AQL query may be provided.

Command Params

Examples

Example 1

Create a Release Bundle using file spec variables.

Example 2

Create a Release Bundle synchronously, in project "project0".

Example 3

Create a Release Bundle using build name and build number variables.

Promote a Release Bundle v2