Try JFrog
Guides
Contact SupportTry JFrog
Start typing to search…
  1. Integrations
  2. Build Integration

Build-Info Repository

The artifactory-build-info repository is a special, local repository in Artifactory designed to store the JSON files that contain your build information. By treating these JSON files as artifacts, Artifactory provides a more robust and efficient way to manage your build history.

This repository is created automatically and serves as the central location for all build information uploaded to your Artifactory instance.

Automatic Deployment

Whenever a build is uploaded to Artifactory—whether from a CI server, the REST API, or the UI—a corresponding build info JSON file is automatically deployed to the artifactory-build-info repository.

Directory Structure

Artifactory organizes the build info files using a clear and consistent structure. The files are not stored in the root of the repository but are automatically placed in the following path:

artifactory-build-info/[build name]/[build number]-[deploy timestamp].json

  • The [build name], [build number], and [deploy timestamp] are automatically generated from the build you uploaded.
  • If you deploy a build with an identical build number and timestamp, it will overwrite the existing build info file rather than creating a new one.

Storing build information this way provides several advantages:

  • Granular Permissions: Manage user and group permissions for your builds using include/exclude patterns, just as you would with any other repository.
  • Simple Replication: Easily replicate your build history to other Artifactory instances, since the build info is stored in a standard repository format.
  • Enhanced Performance: Improve the speed, reliability, and accessibility of the Builds module by centralizing all build data.
❗️

Important

  • Do Not Delete This Repository: The artifactory-build-info repository is a critical system component. You cannot manually delete it. If it is removed, all build history will be permanently lost, and Artifactory will automatically recreate an empty repository in its place.
  • Update Your Cleanup Policies: Since build info files are stored as artifacts, they can be deleted by automated cleanup policies or user plugins. To prevent accidental data loss, you must explicitly exclude the artifactory-build-info repository from any scripts or configurations that clean up artifacts in local repositories.

To view the artifactory-build-info repository:

  1. From the Platform module, navigate to Artifactory > Artifacts.
  2. Use the search bar or browse the repository tree to find artifactory-build-info.

Migrating to the artifactory-build-info Repository

The migration process may be configured through the following system properties. The migration can run on any node.

Property Name
Function

artifactory.migration.job.dbQueryLimit

[Default: 100]

Specifies the number of rows that should be retrieved each time the migration job queries the database for build info json entries that exist in the database but not yet in the build-info repository values.

artifactory.migration.job.batchSize

[Default: 10]

Build info json artifacts are deployed concurrently in batches, then a sleep cycle is initiated. This property specifies the number of artifacts in each batch.

artifactory.build.info.migration.job.queue.workers

[Default: 2]

Specifies the number of concurrent threads that should execute actual build info artifact updates.

Each concurrent artifact update will incur a read from the database to retrieve the build info json, followed by an upload to the build-info repo.

artifactory.migration.job.sleepIntervalMillis

[Default: 5000 milliseconds]

Specifies the duration of the sleep cycle which is initiated after each batch of updates.

artifactory.migration.job.waitForCluster.sleepIntervalMillis

[Default: 300000 milliseconds]

The build-info repository migration can only start when the cluster has been fully upgraded and all nodes run the same minimal required version (6.6.0), where applicable.

This parameter specifies the amount of time the master node will wait between each check for all of the other nodes' current version.

Updated 2 months ago