Using Artifactory 6.x ?
JFrog Artifactory 6.x User Guide
Still using Artifactory 4.x ?
JFrog Artifactory 4.x User Guide
Have a question? Want to report an issue? Contact JFrog support
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.
It is common for a repository to accumulate many different artifacts deployed under the same group (or path prefix) and the same version. This is especially true for snapshot deployments of multi-module projects, where all deployed artifacts use the same version. To delete a version by individually deleting its constituent artifacts can be tedious, and would normally be managed by writing a dedicated script. Artifactory lets you select one of the artifacts in a version and then delete all artifacts with the same version tag in a single click while keeping the corresponding metadata descriptors up to date.
To delete a version, right-click a folder in the Tree Browser and select Delete Versions...
Artifactory drills down into the selected folder and returns with a list of all the groups and versions that can be deleted.
Select the versions you want to clean up and click Delete Selected
Limit to number of versions displayed
To avoid an excessively long search, Artifactory only displays the different version numbers assigned to the first 1000 artifacts found in the selected level of the repository hierarchy. If you do not see the version number you wish to delete, filter the artifacts displayed in the Delete Versions dialog by Group ID or Version number.
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.
Artifactory 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 that are configured with the same package type as the source repository, or configured as generic repositories. This mean, for example, you can only move an artifact from a debian repository to a generic repository or to a local debian repository.
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
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.
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.
Artifactory will run a simulation and display any errors and warnings that would appear when doing the actual operation.
To successfully complete a move, you need to have DELETE permission on your source repository, and DEPLOY permission on your target repository
This ability is configurable by an Artifactory administrator, and if allowed, when a folder is selected the Download function is available in the Actions menu.
The Archive Type. Currently,
Include Checksum Files
Include SHA1, SHA256 and MD5 files - In Artifactory, 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.
An Artifactory administrator can enable complete folder download in the Admin module under Admin | General Configuration. This configuration will apply to all Artiactory users.
|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.|
From version 5.10, 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.