Artifactory REST API: How can I reassociate a build with a deployed artifact?

Question

When you deploy an artifact to Artifactory over an existing artifact, it does not associate it with the build that the existing artifact has.

For example: If you used the Jenkins Artifactory Plugin to deploy three artifacts:

example.jar
example.pom
example.json

Then it would create a new build, associate these artifacts with that build, and deploy the artifacts to the location and repo you specified.

Let's say this deployed to /libs-release-local/example/1.0/ with buildName "example-build" and buildNumber 51

If you looked at the artifacts, you will see on the build tab that it is associated with the build-info.json.

Now, let's say you deploy example.json using the REST API to the same location:

PUT /libs-release-local/example/1.0/example.json

Now the new artifact is not associated with the build-info.json!

How can I deploy the artifact so that it is associated with an already existing build-info.json? (in this example, the "/example-build/51" build).

Not being able to do this causes all sorts of issues (such as when build_promotion is done, it promotes only the previously associated artifacts, and not anything deployed later.)

Answer 1

Artifactory associates the Build Info descriptor with the build artifacts artifacts based on their checksum.

If you look at the JSON which is the Build Info descriptor, you'll be able to see:

{
    ...
    "modules" : [ {
        "id" : "org._10ne.gradle:rest-gradle-plugin:0.2.0",
        "artifacts" : [ {
          "type" : "pom",
          "sha1" : "f0dcec6a603aa99f31990e20c0f314749f0e22ca",
          "md5" : "427dcf49c07cc7be175ea31fd92da44e",
          "name" : "rest-gradle-plugin-0.2.0.pom"
        }, 
        ....
    }
}

A Build Info descriptor describes a "build" which is essentially a single unit of module/s produced by a certain process; this process depends on a specific environment.

You're deploying a new artifact which was not part of the original process or environment that the Build Info describes; if it was, it would have been produced with the exact same checksum as the former artifact

You are basically compromising the integrity of the "build" unit.

The "right" way to do it would be to start a new build process and produce a valid Build Info descriptor.