Using the latest version?
JFrog Container Registry Guide


Skip to end of metadata
Go to start of metadata

Overview

JFrog Container Registry supports move, copy and deletion of artifacts to keep your repositories consistent and coherent. When an artifact is moved, copied or deleted, JFrog Container Registry immediately and automatically updates the corresponding metadata descriptors to reflect the change and keep your repositories consistent with the package clients.

In addition, as a convenience feature, JFrog Container Registry provides a simple way to do a complete version cleanup.

Page Contents



Deleting a Single Item

To delete a single artifact or directory, select the item in the Tree Browser, and click Delete from the Actions menu or the right-click menu.

Once the item is deleted, the corresponding metadata file is updated to reflect the change so the item will not be found in a search.

Deleting a single artifact


Moving and Copying Artifacts

To move or copy an artifact or folder, select it in the Tree Browser and then click Move... or Copy... from the Actions menu or from the right-click menu.

JFrog Container Registry will display a list of repositories from which you need to select your Target Repository for the operation.

The list of target repositories will contain all the local repositories, or virtual repositories with a "Default Deployment Repository" configured with the same package type as the source repository, or configured as generic repositories. This means, for example, you can only move an artifact from a Helm repository to a generic repository or to a local Helm repository. 

Copying artifacts

After selecting your Target Repository, you can specify a custom Target Path if you want your source artifacts moved to a different location the Target Repository.

Copy operations are executed using Unix conventions

Copy operations are executed using Unix conventions. For example, copying org/jfrog/1 from a source repository to org/jfrog/1 in a target repository will result in the contents of the source being copied to org/jfrog/1/1. 
To achieve the same path in the target repository, copy the source into one folder up in the hierarchy. In the above example, that would mean copying source org/jfrog/1 into target org/jfrog.
If you leave the Target Path empty, the source will be copied into the target repository's root folder.

Custom target path supresses cross-layout translation

If you are copying or moving your source artifacts to a repository with a different layout, specifying a Custom Target Path suppresses cross-layout translation. This means that your client may NOT be able to resolve the artifacts, even in cases of a same-layout operation.

Once you have selected your Target Repository (and Custom Target Path if needed), click Move... or Copy... to complete the operation.

All metadata is updated to reflect the operation once completed.

Simulating a Move or Copy

Note that an operation may fail or generate warnings for several reasons. For example, the target repository may not accept all the items due to its own specific policies, or you may not have the required permissions to perform the operation.

Before actually doing an operation, we recommend that you check if it will succeed without errors or warnings by clicking Dry Run.

JFrog Container Registry will run a simulation and display any errors and warnings that would appear when doing the actual operation.

Simulating copy


Permissions required

To successfully complete a move, you need to have DELETE permission on your source repository, and DEPLOY permission on your target repository


Downloading a Folder

JFrog Container Registry allows the download of a complete folder that is selected in the Tree Browser or Simple Browser.

This ability is configurable by an JFrog Container Registry administrator, and if allowed, when a folder is selected the Download function is available in the Actions menu. 

Folder download

Archive Type

The Archive Type. Currently, ziptartar.gz and tgz are supported.

Include Checksum Files

Include SHA1, SHA256 and MD5 files - In JFrog Container Registry, checksum files (.sha1, .sha256 and .md5 files) are displayed and are downloadable in the HTML browsing endpoint (for example, http://<ARTIFACTORY>/artifactory/<REPOSITORY_KEY>), depending on one of the below pre-conditions:

1.The artifact was originally uploaded with its checksum value (i.e the deploying client provided a checksum header such as the "X-Checksum-Sha1" header on the request).

2.The repository Checksum Policy is set to "Trust Server Generated Checksums".

If the latter applies, there is no need to provide the artifact checksums during the upload in order for its checksum files to be visible.

The Download Folder functionality mimics this mechanism, and will write checksum files to the output archive based on the same conditions.

*With remote repository caches, there is no distinction for the checksum policy of the repository. Simply checking this checkbox will always result in checksum files being added.

You can also download a folder using the Rest API.

Configuring Folder Download

 A JFrog Container Registry administrator can enable complete folder download in the Admin module under Admin | General Configuration. This configuration will apply to all Artiactory users.

Folder Download Settings

Max Size
The maximum size (MB) of artifacts that can be downloaded in a folder download.
Max Number of Files
The maximum number of artifacts that may be downloaded from the selected folder and all its sub-folders.
Max Parallel Folder Downloads
The maximum number of concurrent folder downloads allowed.

Blocking Folder Download

When trying to download a folder, if any of the artifacts in that folder are blocked for download, then downloading the folder will fail with an HTTP FORBIDDEN (403) error.


  • No labels