JFrog CLI is a compact and smart client that provides a simple interface to automate access to JFrog products, simplifying your automation scripts and making them more readable and easier to maintain.

JFrog CLI works with JFrog Artifactory, Xray, and Distribution (through their respective REST APIs), 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.

To optimize both uploads and downloads, JFrog CLI avoids transferring artifacts that already exist in the target location. Before uploading, the CLI checks the artifact's checksum with Artifactory. If the artifact is already present in Artifactory’s storage, the CLI skips the upload, and Artifactory may just update its database to reflect the new upload. Similarly, when downloading an artifact, if it already exists in the specified download path, it will be skipped. This checksum optimization also allows you to pause long upload and download operations and resume them later from where you left off.

JFrog CLI simplifies file uploads by supporting wildcard patterns, regular expressions, and ANT patterns, allowing you to easily select all the files you want to upload. You can also use wildcard patterns for downloading files.

Support for popular package managers and build tools

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

Source code and binaries scanning

JFrog CLI empowers you with robust scanning capabilities to ensure the security and compliance of your source code and software artifacts, including containers. It integrates with JFrog Xray, enabling you to scan and analyze your projects and packages, including containers, for vulnerabilities, license compliance, and quality issues. With JFrog CLI, you can proactively identify and mitigate potential risks, ensuring the integrity and safety of your software supply chain.

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 a Build-Info and store the Build-Info in Artifactory.

System Requirements

JFrog CLI runs on any modern OS that fully supports the Go programming language.

Contributing to JFrog CLI Documentation

Your input is valuable in making the JFrog CLI documentation better. You can help enhance and improve it by recommending changes and additions. To contribute, follow these steps:

Go to the documentation project on GitHub:

GitHub - jfrog/documentation and create a pull request with your proposed changes and additions.

Your contributions will be reviewed, and if accepted, they will be merged into the documentation to benefit the entire JFrog CLI community.

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.

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 .

Welcome to the JFrog Applications Doc Hub

Shift Left with JFrog Security

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

Note

Read about additional environment variables at the Welcome to JFrog CLI page.

If you're using JFrog CLI from a bash, zsh, or fish shell, you can install JFrog CLI's auto-completion scripts to improve your command-line experience. Auto-completion helps save time and reduces errors by suggesting potential command options and arguments as you type.

Auto-completion allows you to:

1. Increase Efficiency: Quickly fill in commands and arguments without typing them out fully.

2. Reduce Errors: Minimize typographical errors in commands and options.

3. Discover Commands: Easily explore options for specific commands with in-line suggestions.

What is JFrog CLI?

JFrog CLI is a command-line interface for interacting with JFrog Artifactory and other JFrog products. It simplifies various functions, such as uploading or downloading files, managing repositories, and more. For more information, refer to Jfrog CLI.

How to Enable Auto-Completion?

The method of enabling auto-completion varies based on the shell you are using (bash, zsh, or fish).

Install JFrog CLI with Homebrew

If you're installing JFrog CLI using Homebrew, the bash, zsh, or fish auto-complete scripts are automatically installed. However, you need to ensure that your .bash_profile or .zshrc files are correctly configured. Refer to the Homebrew Shell Completion documentation for specific instructions.

Using Oh My Zsh?

If you are using the Oh My Zsh framework, follow these steps to enable JFrog CLI auto-completion:

1. Open your zsh configuration file, located at $HOME/.zshrc, with any text editor."

   your-text-editor $HOME/.zshrc

2. Locate the line starting with plugins=.

3. Add jfrog to the list of plugins. For example:

   plugins=(git mvn npm sdk jfrog)

4. Save and close the file.

5. Finally, apply the changes by running:

   source $HOME/.zshrc

Other Installation Methods

If you're not using Homebrew or Oh My Zsh, you can manually install the auto-completion scripts for your specific shell:

For Bash

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

jf completion bash --install

Follow the on-screen instructions to complete the installation.

For Zsh

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

jf completion zsh --install

Again, follow the instructions provided during the installation process.

For Fish

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

jf completion fish --install

Ensure you follow the relevant instructions to finalize the setup.

Verifying Installation

After installing the completion scripts, you can verify that auto-completion works by typing jf followed by pressing the Tab key. You should see a list of available commands and options.

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

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

This JFrog AI Assistant Addendum (this “Addendum”) forms part of the JFrog Subscription Agreement or other agreement made by and between the JFrog and Customer (the “Agreement”). Capitalized terms not otherwise defined in the body of this Addendum shall have the respective meanings assigned to them in the Agreement. Your use of the JFrog Platform, as applicable, shall continue to be governed by the Agreement.

THIS ADDENDUM TAKES EFFECT WHEN CUSTOMER (1) CLICKS THE “I ACCEPT” OR SIMILAR BUTTON AND/OR (2) BY ACCESSING OR USING THE APPLICABLE JFROG AI ASSISTANT SERVICE (respectively, the “AI ASSISTANT SERVICE” and “ADDENDUM EFFECTIVE DATE”). BY DOING SO, CUSTOMER: (A) ACKNOWLEDGES THAT IT HAS READ AND UNDERSTANDS THIS ADDENDUM; (B) REPRESENTS AND WARRANTS THAT IT HAS THE RIGHT, POWER, AND AUTHORITY TO ENTER INTO THIS ADDENDUM AND, IF ENTERING INTO THIS ADDENDUM FOR AN ENTITY, THAT IT HAS THE LEGAL AUTHORITY TO BIND SUCH ENTITY TO THIS ADDENDUM; AND (C) ACCEPTS THIS ADDENDUM AND AGREES THAT IT IS LEGALLY BOUND BY ITS TERMS.

IF CUSTOMER DOES NOT AGREE TO THIS ADDENDUM OR IF CUSTOMER IS A COMPETITOR OF JFROG OR ITS AFFILIATES (OR A PERSON OR ENTITY ACTING ON BEHALF OF A COMPETITOR), PLEASE SELECT THE “I DECLINE” OR SIMILAR BUTTON AND/OR DO NOT UNDER ANY CIRCUMSTANCES ACCESS OR USE THE AI ASSISTANT SERVICE.

1. APPLICATION OF THIS ADDENDUM.

a. AI Assistant Service. JFrog offers the applicable AI Assistant Service which references this Addendum, that is designed to enable Customer to: (i) generate or receive Output, in response to Input, for use in connection with the AI Assistant Service; and, if applicable to the specific AI Assistant Service, (ii) view suggested shortcuts and commands, in response to use of the AI Assistant Service by Customer, for use in connection with the AI Assistant Service (collectively, together with any Content, other than Output, provided to Customer by the AI Assistant Service, and any documentation for the AI Assistant Service, the “Service”). This Agreement only applies to the Service provided by JFrog and not to a Service provided by a third party.

b. Relationship with Agreement. In the event of any conflict between this Addendum and the Agreement, this Addendum will control, solely to the extent of the conflict. The Service is part of the “JFrog Platform” and the “JFrog Materials”, in each case, as used in the Agreement. “Customer”, as used herein, means the person or entity other than JFrog, that is party to the Agreement or an Order Form thereunder. “JFrog”, as used herein, means the applicable JFrog Contracting Entity in the Agreement. “Customer Data”, as used in the Agreement, excludes AI Assistant Data.

2. LICENSE TO SERVICE.

The license to the JFrog Platform set forth in the Agreement includes the right and license, during the Agreement Term, for Customer to access and use the Service. Without limiting the restrictions on use of the JFrog Platform set forth in the Agreement, Customer You will not, directly or indirectly, permit, facilitate, or otherwise allow any other person or entity to: (a) access or use the Service, except for Customer Users; (b) access the source code or other underlying components of the Service, including the model, model parameters, or model weights; (c) access, copy, extract, scrape, crawl, or pull from the Service, through manual or automated means, any information, data, materials, text, prompts, images, or other content (“Content”) that has been, is used, or may be used by JFrog, to train, retrain, tune, validate, modify, update, or otherwise improve the Service (“Training Content”); (d) develop, build, train, or run a machine learning or artificial intelligence application, functionality, logic, model, software system, or process on or using the Service; (e) intentionally generate Output that is sensitive, confidential, or proprietary information of any third party without authorization, or collect personal data from the Service; (f) share, generate or prompt any content or engage in behavior that is unlawful, harmful, threatening, obscene, violent, abusive, tortious, defamatory, ridicule, libelous, vulgar, lewd, invasive of another’s privacy, hateful, or otherwise objectionable; (g) upload or transmit any personal data (except for Customer User Information), viruses or other malicious content or code into or through the Service; or (h) access or use the Service in a manner that does not comply with the JFrog Acceptable Use Policy available at https://jfrog.com/acceptable-use-policy/.

3. TERM; TERMINATION.

This Addendum commences on the Addendum Effective Date and will remain in effect until the Agreement expires or is terminated, or this Addendum is terminated by JFrog in accordance with this Section, whichever is the earlier (the “Term”). JFrog may terminate or suspend this Addendum, or the availability of the Service, at any time and for any reason by providing Customer with notice, without liability or other obligation to Customer. Termination of this Addendum will not impact the Agreement. Upon any termination or expiration of this Addendum, Customer will promptly cease access and use of the Service.

4. AI ASSISTANT CONTENT.

a. License to AI Assistant Content. Customer hereby grants JFrog and its Affiliates a non-exclusive, sublicensable, transferable, royalty-free, fully paid-up, worldwide right and license, to use, reproduce, distribute, perform, display, modify, create derivative works of, process, store, and disclose any Content or other: (i) input provided to the Service provided by or on behalf of Customer, which may include Customer Data (“Input”); and (ii) output provided to, or generated for Customer by the Service, in response to use of the AI Assistant Service by Customer or an Input (“Output”), in each case of the foregoing (i) and (ii), for the purposes of billing, capacity planning, compliance, security, integrity, availability, stability, providing the AI Assistant Service as generally available, and, in the event the Customer elects to provide any suggestions, enhancement requests, recommendations, corrections or other feedback, improving the AI Assistant Service and the JFrog Platform. The foregoing grant includes the right and license for JFrog and its Affiliates to use the AI Assistant Content to train, retrain, tune, validate, modify, update, or otherwise improve the Service or the JFrog Platform. “Input” and “Output” are collectively hereinafter referred to as “AI Assistant Content”. The AI Assistant Content is not the “Confidential Information” of Customer. Personal Data shall not be entered as an Input to the Service.

b. Ownership of AI Assistant Content. As between Customer and JFrog, and to the extent permitted by applicable law, Customer: (i) retains ownership rights in Input; and (ii) owns the Output, except to the extent such Output was provided to, or generated for, other JFrog customers by the Service. Customer acknowledges that the Output provided may not be new or unique or protectable under applicable laws and that similar Outputs may be provided to other customers and their users in response to their Inputs into the Service.

c. Processing of AI Assistant Content. You authorize JFrog and its third-party providers to process your AI Assistant Content to provide the Service. You agree that JFrog may use Sub-Processors to provide the Service.

5. REPRESENTATIONS; WARRANTIES; DISCLAIMERS.

Customer represents, warrants, and covenants that Customer owns or otherwise has and will have the necessary rights, licenses, and consents in and relating to the AI Assistant Content such that, as used by JFrog and its Affiliates in accordance with this Addendum, such AI Assistant Content does not and will not infringe, misappropriate, or otherwise violate any intellectual property rights, or other rights, of any third party or violate any applicable law. CUSTOMER ACCEPTS AND AGREES THAT ANY USE OF OR RELIANCE ON OUTPUTS IS AT CUSTOMER’S SOLE RISK AND CUSTOMER WILL NOT RELY ON OUTPUT AS A SOLE SOURCE OF TRUTH OR FACTUAL INFORMATION, OR AS A SUBSTITUTE FOR PROFESSIONAL ADVICE. JFROG DOES NOT ACCEPT LIABILITY OR RESPONSIBILITY FOR ANY INCORRECT, OFFENSIVE, UNLAWFUL, HARMFUL, OR OTHERWISE OBJECTIONABLE OUTPUT. THE OUTPUT DOES NOT REFLECT THE VIEWS, OPINIONS, POLICIES, OR POSITION OF JFROG OR ITS AFFILIATES.

6. INDEMNIFICATION.

Without limiting the scope of the obligations to indemnify and defend under the Agreement, the claims, demands, suits, or proceedings (each, a “Claim”) for which Customer indemnifies and defend JFrog and its Affiliates under the Agreement include Claims arising out of or related to: (a) the Service or Customer’s access and use thereof; (b) any acts or omissions by Customer that constitute a breach of this Addendum; (c) reliance, or use of, any AI Assistant Content; and (d) fraud, gross negligence, or willful misconduct by Customer.

7. MISCELLANEOUS.

Any notice required or permitted by this Addendum may, if sent by JFrog, be delivered electronically, including through the Service or AI Assistant Service. The following terms will survive any termination or expiration of this Addendum: Section 4(a) (License to AI Assistant Content) and Section 5 (Representations; Warranties; Disclaimers) through Section 7 (Miscellaneous), inclusive.

JFrog CLI is a command-line tool that enhances the automation and management of JFrog services, including Artifactory, Xray, and other components within the JFrog ecosystem. Authentication is a vital component of using JFrog CLI, ensuring secure interactions with the JFrog services.

When working with JFrog Xray, you have two primary authentication options: username/password pairs and access tokens. Each method allows you to secure access to your JFrog instance and interact with the API effectively.

Prerequisites

Before proceeding with authentication using JFrog CLI, ensure that you meet the following prerequisites:

1. JFrog CLI Installed: Make sure that you have the JFrog CLI installed on your system. You can download and install it from the.

2. JFrog Account: An active JFrog account with appropriate permissions to access the service. Ensure you have the necessary login credentials (username and password) or an access token.

3. Token Validity (if using access tokens): If you choose to authenticate with an access token, ensure that it is in a valid JWT format and has not expired. Review your token’s scope and permissions to confirm it grants the required access to Xray.

Authentication using CLI

When using JFrog CLI with Xray, authentication is mandatory. JFrog CLI does not support access to Xray without valid authentication credentials. You can authenticate using either a username and password or an access token. Below are detailed instructions for both methods.

• Using password & Username

• Access token

Authenticating with Username and Password

To authenticate using your Xray login credentials:

• Configuration Options

You can configure your credentials permanently using the jf c add command. Alternatively, you can provide your credentials dynamically for each command.

Configure Once Using jf c add

Run the following command:

Follow the prompts to enter the necessary information:

jf c

• Enter a unique server identifier: Your chosen name for this configuration (e.g., xray_server).

• JFrog Platform URL: The base URL for your JFrog instance (e.g., <https://yourjfroginstance.jfrog.io).>

• JFrog username: Your username.

• JFrog password: Your password.

• Using Command Options

For each command, you can specify the following options:

Example Command

Authenticating with an Access Token

To authenticate using an Xray Access Token:

Configuration Options

Similar to username/password authentication, you can configure your access token using the jf c add command, or you can include it directly with each command.

Configure Once Using jf c add

When prompted, enter your access token instead of a password.

Using Command Options

You can specify the following options for authentication:

Example Command

Note

• Security: Ensure that your credentials and access tokens are kept secure and not hardcoded in scripts wherever possible. Consider using environment variables or secure vaults for sensitive information.

• Token Expiration: Access tokens may have an expiration time. Be aware of this and renew your token as needed to maintain access.

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).

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.

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.

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".

Overview

This command is used to clean up files from a Git LFS repository. This deletes all files from a Git LFS repository, which are no longer referenced in a corresponding Git repository.

Commands Params

Examples

Example 1

Cleans up Git LFS files from Artifactory, using the configuration in the .git directory located at the current directory.

Example 2

Cleans up Git LFS files from Artifactory, using the configuration in the .git directory located inside the path/to/git/config directory.

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

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.

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

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

Overview

This command is used to initialize a new JFrog worker.

This command will generate the following files:

• manifest.json – The worker specification which includes its name, the code location, the secrets and all the data that is useful to the worker.

• package.json – The file describing the development dependencies of the worker, this will not be used when executing your worker in our runtime.

• worker.ts – The worker code source, here it will be our sample code for the event.

• worker.spec.ts - The source code of the worker unit tests.

• tsconfig.json - The Typescript configuration file.

• types.ts - A file containing the event's specific types that can be used in the worker code.

Example

Initialize a new BEFORE_DOWNLOAD worker named my-worker.

The JFrog Security documentation has a new home! You can now find it , including sections on:

Overview

Test-run a worker. The worker needs to be initialized before running this command. The command will execute the worker with its local content, so it can be used to test the worker execution before pushing the local changes to the server.

Example

Test-run a worker initialized in the current directory, with a payload located in a file named payload.json from the same directory.

Overview

This command is used to update the worker definition (code, description , filter, secret ...) on your Artifactory instance.

Example

Deploy a worker to server with id my-server.

Overview

This command list all the available events on the platform.

Example

List event supported by a server identified by my-server.

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

Overview

Display in a json format the execution history of a specific worker.

Example

Retrieves the execution history of a worker named my-worker including test runs.

Overview

This command is used to edit a worker manifest in order to add or edit secret that can be used for deployment or/and execution.

Secrets are store encrypted with a master password that will be requested by the command.

Once secrets are added to the manifest the master password will be required by the deploy and test-run commands.

Example

Add a secret name my-secret to a worker initialized in the current directory.

Overview

Edit the manifest of a SCHEDULED_EVENT worker to udpate the schedule criteria.

The worker should be deploy afterward with jf worker deploy for the change to be applied to the server.

Example

Edit a worker manifest so that it is executed every minute.

Overview

List workers saved on your Artifactory instance. The default output is a CSV format with columns name,action,description,enabled.

Example

List all workers registered in a platform named my-platform with detailed data.

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

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.

Example 2

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

Example 3

Ping the Artifactory server. accessible through the specified URL.

The JFrog Security documentation has a new home! You can now find it , including sections on:

This page is about the integration of JFrog Platform Services with JFrog CLI.

Read more about JFrog CLI .

Managing JFrog Workers

Workers is a JFrog Platform service that allows you to extend and control your execution flows. It provides a serverless execution environment. You can create workers to enhance the platform's functionality. Workers are triggered automatically by events within the JFrog Platform, giving you the flexibility to address specific use cases. For on-demand tasks, configure Http-triggered workers.

You can read more about JFrog Workers .

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

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

Overview

Execute an HTTP-triggered worker.

Example

Execute an HTTP-triggered worker initialized in the current directory, with a payload located in a file named payload.json from the same directory.

jf worker execute @payload.json

Execute an HTTP-triggered worker with a payload from the standard input.

jf worker execute - <<EOF
{
  “a”: “key”,
  “an-integer”: 14
}
EOF

Execute an HTTP-triggered worker by providing the payload as an argument.

jf worker execute ‘{“my”:”payload”}’

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

Overview

This command is used to remove a registered worker from you Artifactory instance.

Example

Undeploy a worker named my-worker from an Artifactory instance identified by my-server.

jf worker undeploy --server-id my-server my-worker

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

General

JFrog CLI Plugins allow enhancing the functionality of JFrog CLI to meet the specific user and organization needs. The source code of a plugin is maintained as an open source Go project on GitHub. All public plugins are registered in JFrog CLI's Plugins Registry. We encourage you, as developers, to create plugins and share them publicly with the rest of the community. When a plugin is included in the registry, it becomes publicly available and can be installed using JFrog CLI. Read the JFrog CLI Plugins Developer Guide if you wish to create and publish your own plugins.

Installing Plugins

A plugin which is included JFrog CLI's Plugins Registry can be installed using the following command.

$ jf plugin install the-plugin-name

This command will install the plugin from the official public registry by default. You can also install a plugin from a private JFrog CLI Plugin registry, as described in the Private Plugins Registries section.

Private Plugins Registries

In addition to the public official JFrog CLI Plugins Registry, JFrog CLI supports publishing and installing plugins to and from private JFrog CLI Plugins Registries. A private registry can be hosted on any Artifactory server. It uses a local generic Artifactory repository for storing the plugins.

To create your own private plugins registry, follow these steps.

• On your Artifactory server, create a local generic repository named jfrog-cli-plugins.

• Make sure your Artifactory server is included in JFrog CLI's configuration, by running the jf c show command.

• If needed, configure your Artifactory instance using the jf c add command.

• Set the ID of the configured server as the value of the JFROG_CLI_PLUGINS_SERVER environment variable.

• If you wish the name of the plugins repository to be different from jfrog-cli-plugins, set this name as the value of the JFROG_CLI_PLUGINS_REPO environment variable.

The jf plugin install command will now install plugins stored in your private registry.

To publish a plugin to the private registry, run the following command, while inside the root of the plugin's sources directory. This command will build the sources of the plugin for all the supported operating systems. All binaries will be uploaded to the configured registry.

jf plugin publish the-plugin-name the-plugin-version

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.

Note: Always consider security best practices when handling sensitive information, particularly when using environment variables in CI/CD pipelines.

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

The JFrog Security documentation has a new home! You can now find it here, including sections on:

• CLI

• Frogbot

• IDEs

Overview

The Command Summaries feature enables the recording of JFrog CLI command outputs into the local file system. This functionality can be used to generate a summary in the context of an entire workflow (a sequence of JFrog CLI commands) and not only in the scope of a specific command.

An instance of how Command Summaries are utilized can be observed in the setup-cli GitHub action. This action employs the compiled markdown to generate a comprehensive summary of the entire workflow.

Currently supported commands:

jf rt build-publish

jf rt upload

jf scan

jf build-scan

Notes for Developers

Each command execution that incorporates this feature can save data files into the file system. These files are then used to create an aggregated summary in Markdown format.

Saving data to the filesystem is essential because CLI command executes in separate contexts. Consequently, each command that records new data should also incorporate any existing data into the aggregated markdown. This is required because the CLI cannot determine when a command will be the last one executed in a sequence of commands.

⚠️ Attention: Files Remain After CLI Execution

The CLI does not automatically remove the files as they are designed to remain beyond a single execution. As a result, it is your responsibility to you to manage your pipelines and delete files as necessary. You can clear the entire directory of JFROG_CLI_COMMAND_SUMMARY_OUTPUT_DIR that you have configured to activate this feature.

To use the Command Summaries, you'll need to set the JFROG_CLI_COMMAND_SUMMARY_OUTPUT_DIR environment variable. This variable designates the directory where the data files and markdown files will be stored.

How to Implement?

If you wish to contribute a new CLI command summary to the existing ones, you can submit a pull request once you've followed these implementation guidelines:

1. Implement the CommandSummaryInterface

2. Record data during runtime

Implement the CommandSummaryInterface

type CommandSummaryInterface interface {
   GenerateMarkdownFromFiles(dataFilePaths []string) (finalMarkdown string, err error)
}

Record Data During Runtime

// Initialize your implementation
myNewCommandSummary, err := commandsummary.New(&MyCommandStruct{}, "myNewCommandSummary")
if err != nil {
    return
}
// Record
return myNewCommandSummary.Record(data)

The GenerateMarkdownFromFiles function needs to process multiple data files, which are the results of previous command executions, and generate a single markdown string content. As each CLI command has its own context, we need to regenerate the entire markdown with the newly added results each time.

Example Implementation

// Step 1. Implement the CommandSummaryInterface
type CommandStruct struct{}

type singleRecordedObject struct {
	Name string
}

func (cs *CommandStruct) GenerateMarkdownFromFiles(dataFilePaths []string) (markdown string, err error) {
	// Aggregate all the results into a slice
	var recordedObjects []*singleRecordedObject
	for _, path := range dataFilePaths {
		var singleObject singleRecordedObject
		if err = commandsummary.UnmarshalFromFilePath(path, &singleObject); err != nil {
			return
		}
		recordedObjects = append(recordedObjects, &singleObject)
	}

	// Create markdown
	markdown = results.String()
	return
}

// Step 2. Record data during runtime
func recordCommandSummary(data any) (err error) {
	if !commandsummary.ShouldRecordSummary() {
		return
	}

	commandSummaryImplementation, err := commandsummary.New(&CommandStruct{}, "CommandName")
	if err != nil {
		return
	}

	return commandSummaryImplementation.Record(data)
}

How Does It Work?

Each command that implements the CommandSummaryInterface will have its own subdirectory inside the JFROG_CLI_COMMAND_SUMMARY_OUTPUT_DIR/JFROG_COMMAND_SUMMARY directory.

Every subdirectory will house data files, each one corresponding to a command recording, along with a markdown file that has been created from all the data files. The function implemented by the user is responsible for processing all the data files within its respective subdirectory and generating a markdown string.

JFROG_CLI_COMMAND_SUMMARY_OUTPUT_DIR/JFROG_COMMAND_SUMMARY  
│
└─── Command1
│       datafile1.txt
│       datafile2.txt
│       markdown.txt
│   
└─── Command2
        datafile1.txt
        datafile2.txt
        markdown.txt

The JFrog Security documentation has a new home! You can now find it , including sections on:

The JFrog Security documentation has a new home! You can now find it , including sections on:

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
curl -fsSL 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

Note: If you are using any shim-based version managers (like Volta, nvm, etc.) for a package, it is advised to avoid using npm-based installation; instead, please use other installation options JFrog provides.

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

Note: If you are using any shim-based version managers (like Volta, nvm, etc.) for a package, it is advised to avoid using npm-based installation; instead, please use other installation options JFrog provides.

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

Note: If you are using any shim-based version managers (like Volta, nvm, etc.) for a package, it is advised to avoid using npm-based installation; instead, please use other installation options JFrog provides.

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";

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.

1. Install JFrog CLI on the primary node machine of the source instance as described here.

2. Configure the connection details of the source Artifactory instance with your admin credentials by running the following command from the terminal.

   Copy

   jf c add source-server

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.

4. If the source instance has internet access, you can install the data-transfer user plugin on the source machine automatically by running the following command from the terminal jf rt transfer-plugin-install source-server. If however the source instance has no internet access, install the plugin manually as described here.

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

Install JFrog CLI on any machine that has access to both the source and the target JFrog instances. To do this, follow the steps described here.

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

jf rt transfer-files source-server target-server

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.

jf rt transfer-files --status

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.

jf rt transfer-files -h

If the traffic between the source and target instance needs to be routed through an HTTPS proxy, refer to this section.

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.

jf rt transfer-files --stop

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

While the file transfer is running, monitor the load on your source instance, and if needed, reduce the transfer speed or increase it for better performance. For more information, see the Controlling the File Transfer Speed section.

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:

Read more about how the transfer files works in this section.

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.

   Copy

   jf rt transfer-plugin-install source-server --dir "[plugin files dir]"

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:

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

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:

   Copy

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

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.

   Copy

   jf c add source-server

4. Configure the connection details of the target Artifactory instance as follows.

   Copy

   jf c add target-server

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.

jf rt transfer-settings

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.

1. Define the proxy details in the source instance UI as described in the Managing Proxies documentation.

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:

   Copy

   jf rt transfer-files my-source my-target --proxy-key my-proxy-key

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 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 command:

Example 2

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

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:

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.

Overview

allow enhancing the functionality of JFrog CLI to meet the specific user and organization needs. The source code of a plugin is maintained as an open source Go project on GitHub. All public plugins are registered in . We encourage you, as developers, to create plugins and share them publicly with the rest of the community. When a plugin is included in the registry, it becomes publicly available and can be installed using JFrog CLI. Version 1.41.1 or above is required. Plugins can be installed using the following JFrog CLI command:

This article guides you through the process of creating and publishing your own JFrog CLI Plugin.

Creating your first plugin

Prepare your development machine

• Make sure Go 1.17 or above is installed on your local machine and is included in your system PATH.

• Make sure git is installed on your local machine and is included in your system PATH.

Build and run your first plugin

1. Go to .

2. Press the Use this template button to create a new repository. You may name it as you like.

3. Clone your new repository to your local machine. For example:

1. Run the following commands, to build and run the template plugin.

1. Open the plugin code with your favorite IDE and start having fun.

What can plugins do?

Well, plugins can do almost anything. The sky is the limit.

1. You have access to most of the JFrog CLI code base. This is because your plugin code depends on the module. It is a dependency declared in your project's go.mod file. Feel free to explore the jfrog-cli-core code base, and use it as part of your plugin.

2. You can also add other Go packages to your go.mod and use them in your code.

3. You can package any external resources, such as executables or configuration files, and have them published alongside your plugin. Read more about this

Including plugins in the official registry

General

To make a new plugin available for anyone to use, you need to register the plugin in the JFrog CLI Plugins Registry. The registry is hosted in . The registry includes a descriptor file in YAML format for each registered plugin, inside the plugins directory. To include your plugin in the registry, create a pull request to add the plugin descriptor file for your plugin according to this file name format: your-plugin-name.yml.

Guidelines for developing and publishing plugins

To publish your plugin, you need to include it in . Please make sure your plugin meets the following guidelines before publishing it.

• Read the document. You'll be asked to accept it before your plugin becomes available.

• Code structure. Make sure the plugin code is structured similarly to the . Specifically, it should include a commands package, and a separate file for each command.

• Tests. The plugin code should include a series of thorough tests. Use the as a reference on how the tests should be included as part of the source code. The tests should be executed using the following Go command while inside the root directory of the plugin project. Note: The Registry verifies the plugin and tries to run your plugin tests using the following command. go vet -v ./... && go test -v ./...

• Code formatting. To make sure the code formatted properly, run the following go command on your plugin sources, while inside the root of your project directory. go fmt ./...

• Plugin name. The plugin name should include only lower-case characters, numbers and dashes. The name length should not exceed 30 characters. It is recommended to use a short name for the users' convenience, but also make sure that its name hints on its functionality.

• Create a Readme. Make sure that your plugin code includes a README.md file and place it in the root of the repository. The README needs to be structured according to the README. It needs to include all the information and relevant details for the relevant plugin users.

• Consider create a tag for your plugin sources. Although this is not mandatory, we recommend creating a tag for your GitHub repository before publishing the plugin. You can then provide this tag to the Registry when publishing the plugin, to make sure the correct code is built.

• Plugin version. Make sure that your built plugin has the correct version. The version is declared as part of the plugin sources. To check your plugin version, run the plugin executable with the -v option. For example: ./my-plugin -v. The plugin version should have a v prefix. For example v1.0.0 and it should follow the semantic versioning guidelines.

Important notes

• Please make sure that the extension of your plugin descriptor file is yml and not yaml.

• Please make sure your pull request includes only one or more plugin descriptors. Please do not add, edit or remove other files.

YAML format example

• pluginName - The name of the plugin. This name should match the plugin name set in the plugin's code.

• version - The version of the plugin. This version should have a v prefix and match the version set in the plugin's code.

• repository - The plugin's code GitHub repository URL.

• maintainers - The GitHub usernames of the plugin maintainers.

• relativePath - If the plugin's go.mod file is not located at the root of the GitHub repository, set the relative path to this file. This path should not include the go.mod file.

• branch - Optionally set an existing branch in your plugin's GitHub repository.

• tag - Optionally set an existing tag in your plugin's GitHub repository.

Publishing a new version of a published plugin

To publish a new version of your plugin, all you need to do is create a pull request, which updates the version inside your plugin descriptor file. If needed, your change can also include either the branch or tag.

Setting up a private plugins registry

In addition to the public official JFrog CLI Plugins Registry, JFrog CLI supports publishing and installing plugins to and from private JFrog CLI Plugins Registries. A private registry can be hosted on any Artifactory server. It uses a local generic Artifactory repository for storing the plugins.

To create your own private plugins registry, follow these steps.

• On your Artifactory server, create a local generic repository named jfrog-cli-plugins.

• Make sure your Artifactory server is included in JFrog CLI's configuration, by running the jf c show command.

• If needed, configure your Artifactory instance using the jf c add command.

• Set the ID of the configured server as the value of the JFROG_CLI_PLUGINS_SERVER environment variable.

• If you wish the name of the plugins repository to be different from jfrog-cli-plugins, set this name as the value of the JFROG_CLI_PLUGINS_REPO environment variable.

• The jf plugin install command will now install plugins stored in your private registry.

To publish a plugin to the private registry, run the following command, while inside the root of the plugin's sources directory. This command will build the sources of the plugin for all the supported operating systems. All binaries will be uploaded to the configured registry.

jf plugin publish the-plugin-name the-plugin-version

Testing your plugin before publishing it

When installing a plugin using the jf plugin install command, the plugin is downloaded into its own directory under the plugins directory, which is located under the JFrog CLI home directory. By default, you can find the plugins directory under ~/.jfrog/plugins/. So if for example you are developing a plugin named my-plugin, and you'd like to test it with JFrog CLI before publishing it, you'll need to place your plugin's executable, named my-plugin, under the following path -

If your plugin also uses , you should place the resources under the following path -

Once the plugin's executable is there, you'll be able to see it is installed by just running jf.

Having your plugin use external resources

General

In some cases your plugin may need to use external resources. For example, the plugin code may need to run an executable or read from a configuration file. You would therefore want these resources to be packaged together with the plugin, so that when it is installed, these resources are also downloaded and become available for the plugin.

How can you add resources to your plugin?

The way to include resources for your plugin, is to simply place them inside a directory named resources at the root of the plugin's sources directory. You can create any directory structure inside resources. When publishing the plugin, the content of the resources directory is published alongside the plugin executable. When installing the plugin, the resources are also downloaded.

How can your plugin code access the resources?

When installing a plugin, the plugin's resources are downloaded the following directory under the JFrog CLI home -

This means that during development, you'll need to make sure the resources are placed there, so that your plugin code can access them. Here's how your plugin code can access the resources directory -

Overview

This page describes how to use the JFrog CLI to create external 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 .

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

Package Evidence

Build Evidence

Release Bundle v2 Evidence

Command parameters

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

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

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

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-name 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:

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

Sample commands

Artifact Evidence Sample

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

Build Evidence Sample