Welcome to the JFrog Applications Doc Hub

Shift Left with JFrog Security

JFrog CLI supports uploading and downloading symlinks (soft links) between your local file system and Artifactory.

Symlinks are stored in Artifactory as zero-byte files with the following properties:

• symlink.dest: The path on the original file system to which the symlink points.

• symlink.destsha1: The SHA1 checksum of the value in the symlink.dest property.

To upload symlinks, run the jf rt upload command 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 exists and has the correct SHA1 checksum. To add this validation, use the --validate-symlinks option with the jf rt download command.

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 or HTTPS proxy. To configure proxy support, you must set the HTTP_PROXY or HTTPS_PROXY environment variable with the proxy URL.

The HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables are industry standards for proxy configuration.

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:

This page describes how to use JFrog CLI with JFrog Platform Services.

Read more about JFrog CLI .

Managing JFrog Workers

Workers is a JFrog Platform service that you can use 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, which addresses specific use cases. For on-demand tasks, configure HTTP-triggered workers.

For more information 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 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

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.

jf worker server deploy --server-id my-server

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

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

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

Advanced upload and download capabilities

With JFrog CLI, you can upload and download artifacts concurrently using a configurable number of threads to help your automated builds run faster. For large 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 the artifact already exists in Artifactory's storage, the CLI skips sending the file, and Artifactory only updates its database if necessary. Similarly, when you download an artifact, it will be skipped if it already exists in the target download path. Checksum optimization also allows you to pause long upload and download operations and resume them later from where they 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 build 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, you gain traceability and analysis capabilities to improve the quality and security of your builds. The Build-Info encompasses project module details, artifacts, dependencies, environment variables, and more. It is collected and output in a JSON format, facilitating easy access to information about the build and its components. JFrog CLI can create and store the Build-Info in Artifactory.

For more information, see .

Overview

Use this command to verify that Artifactory is accessible by sending an application ping to Artifactory.

Commands Params

Examples

Example 1: Ping the default server

Pings the configured default Artifactory server.

Example 2: Ping a specific server by ID

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

Example 3: Ping a specific server by URL

Pings the Artifactory server accessible at the specified URL.

Overview

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

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

Examples

Example 1: Upload Files into Dynamically Named Directories

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

Example 2: Upload Files with Modified Names

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

Example 3: Organize Uploaded Files by Extension

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

Example 4: Copy Files and Append a Suffix

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

Overview

This command executes a cURL command using the Artifactory details you have configured. The command expects the cURL client to be included in your 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: Send a Request to the Default Server

Execute the cURL client to send a GET request to the /api/build endpoint on the default configured Artifactory server.

Example 2: Send a Request to a Specific Server

Execute the cURL client to send a GET request to the /api/build endpoint on the Artifactory server configured with the ID my-rt-server.

Overview

Use this command to clean up a Git LFS repository. This command deletes all files from a Git LFS repository in Artifactory that are no longer referenced in a corresponding Git repository.

Commands Params

Examples

Example 1: Clean Up Using the Current Directory

This example cleans up Git LFS files from Artifactory, using the configuration from the .git directory located in the current directory.

Example 2: Clean Up Using a Specific Path

This example cleans up Git LFS files from Artifactory, using the configuration from the .git directory located inside the path/to/git/config directory.

Overview

Use this command to test-run a Worker. You must initialize the Worker before running this command. The command executes the Worker with its local content, so you can use it to test the Worker's execution before pushing local changes to the server.

Example

This example test-runs a Worker that has been initialized in the current directory, using a payload from a file named payload.json in the same directory.

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

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.

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.

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

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

Overview

This command list all the available events on the platform.

Example

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

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.

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

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.

General

JFrog CLI plugins enhance the functionality of JFrog CLI to meet 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 developers to create plugins and share them publicly with the community. When a plugin is included in the registry, it becomes publicly available and can be installed using JFrog CLI. For more information, see the if you want to create and publish your own plugins.

Installing Plugins

A plugin which is included can be installed using the following command.

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 registries. A private registry can be hosted on any Artifactory server and uses a local generic Artifactory repository for storing the plugins.

To create your own private plugins registry:

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

2. Verify that your Artifactory server is configured in JFrog CLI by running the jf c show command.

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

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

5. To use a repository name other than jfrog-cli-plugins, set the custom 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 your private registry, run the following command from the root directory of the plugin's source code. This command builds the plugin's source for all supported operating systems, and all binaries will be uploaded to the configured private registry.

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:

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:

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.

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

• (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.

Overview

This command is used to initialize a new JFrog worker.

This command generates the following files:

• manifest.json – Contains the Worker specification, including its name, code location, secrets, and other data useful to the Worker.

• package.json – Describes the development dependencies of the Worker. This file is not used when executing your Worker in the runtime.

• worker.ts – The Worker source code, populated with sample code for the event.

• worker.spec.ts - The source code for the Worker's 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 BEFORE_DOWNLOAD Worker

This example initializes a new BEFORE_DOWNLOAD Worker named my-worker.

jf worker init BEFORE_DOWNLOAD my-worker

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. Describe your desired actions, and the assistant generates commands with all necessary parameters, whether you are 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 does not maintain a chat history. This tool helps you 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:

1. Open your terminal. Your command prompt is displayed.

2. Verify that your CLI version is 2.69 or higher by running the following command:

3. Type the following command to initiate the AI assistant:

4. Provide your request when you see the prompt. Describe in natural language what you would like the JFrog CLI to do. For example:

5. Receive the generated command. The AI assistant processes your request and outputs the corresponding JFrog CLI command. For the example above, it generates:

6. Execute or modify the command. 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

Read about additional environment variables at the page.

Overview

The Command Summaries feature records 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.

For example, the setup-cli action uses 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 to the file system. These files are then used to create an aggregated summary in Markdown format.

Saving data to the file system is essential because each CLI command executes in a separate context. 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.

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

To use Command Summaries, you will 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.

⚠️ 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?

To contribute a new CLI command summary, follow these implementation guidelines and then submit a pull request.

1. Implement the CommandSummaryInterface

2. Record data during runtime

Implement the CommandSummaryInterface

Record Data During Runtime

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

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 you implement is responsible for processing all the data files within its subdirectory and generating a markdown string.

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 JFrog CLI Download & Install.

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

jf rt
ping
--url
"<https://yourjfroginstance.jfrog.io/xray>"
--user
"your_username"
--password
"your_password"

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

jf rt
ping
--url
"<https://yourjfroginstance.jfrog.io/xray>"
--access-token
"your_access_token"

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

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

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.

Overview

Use the transfer-files command to transfer (copy) all files stored in one Artifactory instance to a different Artifactory instance. The command allows transferring files from 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

• Artifacts in remote repository caches are not transferred.

• The file 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.

• The custom properties of newly created or modified files are updated on the target instance. However, if only the custom properties of a file were modified on the source, but not the file's content, the properties are not modified on the target instance by the process.

• The source and target repositories must have the same name and type.

• Since the files are pushed from the source to the target instance, the source instance must have a network connection to the target.

Before You Begin

• Ensure that you can log in to the UI of both the source and target instances with a user that has admin permissions and that you have the connection details for both instances.

• Ensure that all repositories on the source Artifactory instance that you want to transfer also exist on the target instance with the same name and type.

• 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 File Transfer

To set up the source instance for file transfer, you must install the data-transfer user plugin on 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. For more information, see Installing JFrog CLI.

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 the JFrog installation directory, which usually points to the /opt/jfrog directory. If the variable is not set, set its value to point to the correct directory. For more information, see the JFrog Product Directory Structure article.

4. If the source instance has internet access, you can install the data-transfer user plugin automatically by running jf rt transfer-plugin-install source-server from the terminal. If the source instance does not have internet access, install the plugin manually. For more information, see Installing the Data-Transfer User Plugin Manually.

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 files from the source 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 files in the repository to the target.

  • Phase 2: Pushes files that were created or modified after Phase 1 started (diffs).

  • Phase 3: Attempts to push files that failed to be transferred in earlier phases or previous executions.

• If Phase 1 is complete for a repository, subsequent runs of the jf rt transfer-files command will only trigger Phase 2 and Phase 3. You can run the command as many times as needed until you are ready to move your traffic to the target instance permanently.

Tip: 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 file transfer process.

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 to transfer files created or updated after previous runs. To achieve this, JFrog CLI stores the current state of the file transfer process in a directory named transfer located under the JFrog CLI home directory (usually ~/.jfrog/transfer).

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

To ignore the stored state and restart the file transfer from scratch, 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

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

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 -

Web Sign-in to the JFrog Platform

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

Create Access Tokens

Use this command to create Access Tokens in the JFrog Platform. By default, a user-scoped token is created. Administrators can provide the scope explicitly with --scope, or implicitly with --groups or --grant-admin.

Commands Arguments

Examples

Example 1

Create an access token for the current user on the default server configured by the jf c add command.

jf atc

Example 2

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

jf atc toad

Add and Edit Configured Servers

The config add or config edit commands add and edit JFrog Platform server configurations, which are stored in JFrog CLI's configuration storage. Other commands can use these configured servers. You can override the configured server details for any command by passing in alternative values for the URL and sign-in credentials. The configured values are saved in a file under the JFrog CLI home directory.

Remove Configured Servers

The config remove command removes a JFrog Platform server configuration from JFrog CLI's configuration storage.

Show Configured Servers

The config show command shows the stored configuration. To show a specific server's configuration, provide its ID as an argument.

Set a Server as Default

The config use command sets a configured server as the default for subsequent commands.

Export and Import Configuration

The config export command generates a token that stores a server configuration. The config import command uses this token to import the configuration and save it to JFrog CLI's configuration storage.

Export

Import

Sensitive Data Encryption

File-Based Encryption

Starting from version 1.37.0, JFrog CLI supports encrypting sensitive configuration data using an encryption key stored in a file. To enable encryption:

1. Generate a random 32-character master key. The key must be exactly 32 characters. For example: f84hc22dQfhe9f8ydFwfsdn48!wejh8A

2. Create a file named security.yaml under ~/.jfrog/security. If you customized the JFrog CLI home directory using the JFROG_CLI_HOME_DIR environment variable, create the file in the configured home directory.

   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 is encrypted the next time JFrog CLI accesses it. If you have existing configurations, you must reconfigure the servers.

Warning: When upgrading JFrog CLI from a version prior to 1.37.0, the ~/.jfrog directory is backed up to ~/.jfrog/backup. After enabling 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 encryption using a key stored in an environment variable. To enable this method:

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 is encrypted the next time JFrog CLI accesses it. If you have existing configurations, you must reconfigure the servers.

Overview

To perform complex file operations, you may need to use several CLI commands. For example, you might need to upload different sets of files to different repositories. To simplify these complex operations, use the JFrog CLI download, upload, move, copy, and delete commands with the --spec option. This option uses a File Spec to replace inline command arguments and options. Similarly, you can create and update release bundles by providing the --spec command option.

Each command uses a file specification array in JSON format. The schema for each command is described in the following sections. Note that if a command is issued with both inline options and a File Spec, the inline options override the corresponding settings in the File Spec.

File Spec Schemas

The following sections show the JSON schema for the different commands that support File Specs.

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 with File Specs.

Example 1

Download all files from the all-my-frogs/ directory in the my-local-repo repository to the local froggy/ directory.

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

Example 2

Download all files from all-my-frogs/ in my-local-repo, but only include files that are artifacts of build number 5 of the my-build 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/"
    }
  ]
}