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.