JFrog Bintray is being sunset. Please refer this blog post for more detail.
A Remote Repository defined in Artifactory serves as a caching proxy for a registry managed at a remote URL such as https://center.conan.io, or even a Conan repository managed at a remote site by another instance of Artifactory.
Conan packages requested from a remote repository are cached on demand. You can remove Conan packages from the remote repository cache, however, you can not manually push Conan files to a remote Conan repository.
To define a remote repository to proxy a remote repository follow the steps below:
To resolve Conan remote packages, aggregate the remote repository in a virtual repository as they cannot be resolved directly from the remote repositories.
A Virtual Repositories defined in Artifactory aggregates Conan packages from both local and remote repositories that are included in the virtual repositories. Using virtual repositories can be very useful since users will continue to work with the virtual repository while the admin can manage the included repositories, replace the default deployment target and those changes will be transparent to the users.
To define a virtual Conan repository follow these steps:
Set the Repository Key value.
Once the Conan client is installed, you can access Conan repositories in Artifactory through its command line interface. You can only install packages from or export packages to your Artifactory local Conan repository using the Conan client.
Don't let Conan terminology confuse you. For the purposes of this integration, the Conan "Remote" is actually the Artifactory local repository you have created for Conan packages.
Once you have created your Conan repository, select it in the Tree Browser view in the Application module, Artifactory | Artifacts tab, and click Set Me Up to see the code snippets you will need in order to use your repository as a source to install packages and as a target for export.
In the sections below, <REMOTE> is used to denote the logical name you set with which the Conan client can identify the Conan local repository in Artifactory.
To use your local repository with Conan, you first need to add it as a Conan "Remote" to the client as follows:
conan remote add <REMOTE> http://<ARTIFACTORY_URL>/api/conan/<REPO_KEY>
<REPO_KEY> is the repository key.
When accessing a Conan repository through Artifactory, the repository URL must be prefixed with api/conan in the path. This applies to all Conan commands including
For example, if you are using Artifactory standalone or as a local service, you would access your Conan repositories using the following URL:
Or, if you are using Artifactory Cloud, the URL would be:
To authenticate the Conan client to Artifactory you need to log in using:
conan user -p <PASSWORD> -r <REMOTE> <USERNAME>
If Artifactory is configured for anonymous access, you may skip authenticating the Conan client.
Artifactory supports Conan repositories with Allow Anonymous Access enabled.
When Allow Anonymous Access is enabled, Artifactory will not query the Conan client for authentication parameters by default, so you need to indicate to Artifactory to request authentication parameters in a different way.
You can override the default behavior by setting the Force Authentication checkbox in the New or Edit Repository dialog.
When set, Artifactory will first request authentication parameters from the Conan client before trying to access this repository.
To install dependencies from Artifactory as defined in your
conanfile.txt file use:
conan install . -r <REMOTE>
To upload packages to your Artifactory local Conan repository use:
conan upload <RECIPE> -r <REMOTE> --all
Where <RECIPE> specifies your Conan recipe reference formatted <NAME>/<VERSION>@<USER>/<CHANNEL>
Artifactory lets you view selected metadata of a Conan package directly from the UI.
In the Application module, Artifactory | Artifacts tab, Tree Browser, and drill down to select the package file you want to inspect. The metadata is displayed in the Conan Info tab. The specific information displayed depends on the tree item you have selected. Selecting the root item of a package displays details of the Conan recipe used to upload the package.
If you select one of the packages, you get detailed Conan Package info including Settings, Options and dependencies ("Requires")
Conan server API v2 is supported and introduces an extension of the binary layout to support Conan Package revisions. Revisions allow you to change your artifacts while keeping the same Conan reference and is intended to achieve package immutability, by preventing data from being overwritten on the server.
This example shows the layout with "9999" as the <packageId>, "1" is the Recipe Revision, and "4" is the Package Revision.
Revisions Support By Conan Client
When the Revision features is enabled, the Conan client searches for the latest revision in Artifactory per reference, unless specified otherwise by the user. It is not mandatory to upgrade your conan client version to use Artifactory 6.9 however if you want to work with revisions you need to download use Conan client 1.13 with the revision mode enabled.
The Conan client, by default, searches for the latest revision in Artifactory per reference, unless specified otherwise by the user.
Artifactory 6.9.0 provides backward compatibility for packages created with Conan server API v1 by automatically migrating the Conan server API v1 binary layout to the new format.
Migration to Conan server API V2 starts after the upgrade process is complete (in all nodes in case of High Availability) and all Conan API endpoints are blocked and cannot be accessed.
After migration, the default revision for all Conan server API v1 packages is set to "0" for both Recipe revision and Package revision, and endpoints will be accessible again.
By default, two threads are dedicated for the migration job. Before upgrading from versions previous to Artifactory 6.9, you can modify this setting in the
$JFROG_HOME/artifactory/etc/artifactory.system.properties file (
$JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties if modifying 7.x).
Note that you can allocate more threads during the migration process but need to restart Artifactory.
artifactory.conan.v2.migration.job.queue.workers = 2 (default)
Use the Conan client to deploy your packages. The Conan client will by default request the latest revision of a Conan reference requested.
Upon deployment using the Conan client, a .timestamp file is created under each revision root for each Recipe and Package revision root.
This file contains the epoch time of deployment (in milliseconds, for example, 1547984992855) and is created only when using the Conan client.
Do not deploy the Conan packages in the UI or via REST API deployment to prevent index consistency and failed resolutions.
Artifactory lets you view selected metadata of a Conan package directly from the UI. In the Artifacts tab, select Tree Browser and drill down to select the package file you want to inspect. The metadata is displayed in the Conan Info tab. The specific information displayed depends on the tree item you have selected. Selecting the root item of a package displays details of the Conan recipe used to upload the package.
From Artifactory 6.9.0, Conan v2 is supported and introduces a new Conan format layout to support the Revisions attribute.
The following example shows a package with the default revision "0 "for both Recipe and Package.