5 Special Repositories in Artifactory You Should Know About

Note: This blog post was recently updated on June 16, 2021.

Among the many different types of binary repositories managed within JFrog Artifactory as an artifact repository, there are 5 very useful repositories that you may have not noticed. Just like all repositories in Artifactory, these also store your binaries with all the added benefits of Artifactory, but serve a bit differently in their usage. Here’s a glimpse into these repositories and how they can enhance your JFrog experience.

1. Generic Repositories

This type of repository has no particular type and can be used to upload packages in any format. Generic repositories do not maintain separate package indexes, because they are not specific to any package type. They are useful when you want to proxy unsupported package types, store installers, navigation files, audio files, etc.

2. Build Info Repository

This default artifactory-build-info repository was introduced in Artifactory version 6.6 and replaced the old mechanism to store ‘build-info’ files as blobs in the Artifactory database. This artifactory-build-info repository stores all build info files uploaded to Artifactory by the different CI server plugins, including: the Artifactory Jenkins Plugin, JFrog CLI, and directly through the Build Upload REST API or Artifactory UI. Build information is available using the REST API and the Builds page in the Artifactory UI.

This new repository introduced a new set of user/group permissions that define access to the ‘build-info’ files. These are equivalent to managing permissions on repositories with include/exclude patterns on ‘build-info’ JSON paths, in the ‘build-info’ repository. Permissions can be automated using the “Create or Replace Permission Target” REST API call, which now consumes the V2 JSON with a new section for ‘build-info’ permissions.

For example, the following cURL and build-info-permission.json define a new permission target called “java-developers”, for a build called “test-maven”:

cURL command

curl -uadmin:password -XPUT "http://localhost:8081/artifactory/api/v2/security/permissions/java-developers" -H "Content-type: application/json" -T build-info-permission.json

build-info-permission.json

{
  "name": "java-developers",
  "repo": {
    "include-patterns": ["**"] (default),
    "exclude-patterns": [""] (default),
    "repositories": ["generic-local"],
    "actions": {
          "users" : {
            "test1": ["read","write","manage"],
            "test2" : ["write","annotate", "read"]
          },
          "groups" : {
            "group1" : ["manage","read","annotate"],
            "readers" : ["read"]
          }
    }
  },
  "build": {
      "include-patterns": ["test-maven/**"] (default),
      "exclude-patterns": [""] (default),
      "repositories": ["artifactory-build-info"] (default, can't be changed),
      "actions": {
          "users" : {
            "test1": ["read","manage"],
            "test2" : ["write"]
          },
          "groups" : {
            "group1" : ["manage","read","write","annotate","delete"],
            "readers" : ["read"]
          }
      }
  }
}

Note: When upgrading Artifactory to version 6.6 and above, a migration process will start to move all the ‘build-info’ files from the database to the new ‘artifactory-build-info’ repository. You can control the migration process through the use of a few system properties that can be added to the ‘artifactory.system.properties’ file located in $ARTIFACTORY_HOME/etc.

Additional enhancements include:

• Improved accessibility to the ‘build-info’ JSON files and overall performance of the Builds module.
• ‘build-info’ replication to other instances, since they are stored as artifacts in a repository
  (Available using REST API only. Configuring replication for this repository through the UI will be added in future releases).

3. Release Bundles Repository

This immutable release-bundles repository will protect your artifacts as part of the Enterprise+ distribution flow. Artifacts that have been created and signed are automatically copied and saved into this separate repository where their contents can not be edited or removed. This ensures consistency of distribution among target instances. Even if the original artifacts are removed from the original repository, they will continue to stay in the release bundle repository, available for distribution. These release bundles are created and managed in JFrog Distribution, and generally distributed from a source Artifactory instance to Artifactory Edge nodes.

* Available for Enterprise+ when upgrading to both Artifactory 6.5 and Distribution 1.3.

4. Smart Remote Repository

This smart remote repository can proxy to a local or remote repository in another instance of Artifactory. This repository acts just like any remote repository and provides additional benefits such as combined reported download stats, synchronized properties, remote repository browsing and source absence detection.

Here’s how you can easily configure your smart remote repository:

5. Federated Repository

This bi-directional federated repository supports seamless synchronization of artifacts and their metadata across different JFrog Platform Deployments. The federation includes federated repositories from different Platform Deployments, creating a datacenter-transparent repository between different remote locations or different instances of the JFrog Platform. The sync process is automatic and transparent to the user, making this type of repository useful for achieving instant artifact and metadata mirroring.

* Available with Enterprise and Enterprise+ subscriptions

Here’s how you can easily configure your federated repository:

Now that you know about these 5 repositories, get going and try them out!