Nuget upload via jfrog rt upload produces build-info metadata of type generic

[s-geiger-si]

Describe the bug

When we upload builds to artifactory as far as I understand its important to pay attention that we do not mix artifacts of different types into the same builds. For example, typically one would not want to include a docker image and a generic artifact in the same build. The reason for this is, when we promote a build from one repository to another all its artifacts will be copied or moved to the specified target repository. So for example if a build contains a mix of docker and generic artifacts and we promote the build from a a docker dev repository into a docker stable repository, then as a result the generic artifacts will be moved from the generic dev repository into the stable docker repository which is usually not what we want.

As a sanity check we have added a heuristic to our CI/CD pipelines to check if the partial build info files contain a mix of different build types. If this is the case we cancel the pipeline and require that this happens in different builds. This approach works fine for most repositories (i.e., docker, npm), but it breaks with nuget, because the documented approach to upload a nuget package is to use jfrog rt upload to upload the nuget files.

To publish your NuGet packages to Artifactory, use the jf rt upload command.

see: https://jfrog.com/help/r/jfrog-cli/building-nuget-packages

It would be nice if we could have a semantically robust way to upload artifacts according to their corresponding repository type, such that this will be correctly reflected in the partials file.

I am not sure if it would be possible to introduce some argument to the upload comment (i.e., --artifact-type=nuget) to correctly set the artifact type in the partial file, or if its possible to derive the artifact type from the target repository into which the upload command is uploading (which in this case is a nuget repository). But it would be great if there was a way to produce semantically consistent partial files that match the repository type that we are working with.

In general, but this is not related to this bug it is my opinion that mixing different artifact types the same build in Artifactory should either be prevented all together or there should be better support for promotion of mixed artifacts (i.e., by specifying one target repository for each type), if there is a valid use case for this.

Current behavior

The partial file looks as following:

{
  "Type": "generic",   <-- should be 'nuget' instead of 'generic'
  "Artifacts": [
    {
      "name": "baz-1.2.3.nupkg",
      "type": "nupkg",
      "path": "foo/bar/baz.nupkg",
      "sha1": "...",
      "md5": "...",
      "sha256": "..."
    }
  ],
  "Timestamp": 1681744674356
}

Reproduction steps

1. Run any sequence of jobs that produce nuget partial files such as jf rt nuget restore or jf rt nuget pack
2. Run jf rt upload for nupkg file.

Observer that the hidden partials folder now contains one partials file with "Type"="nuget" and another partials file with "Type"="generic".

Expected behavior

I need a way to produce a semantically matching partial file that says type 'nuget':

{
  "Type": "nuget",   <--- get a nuget type in the partial after uploading .nupkg to artifactory server
  "Artifacts": [
    {
      "name": "baz-1.2.3.nupkg",
      "type": "nupkg",
      "path": "foo/bar/baz.nupkg",
      "sha1": "...",
      "md5": "...",
      "sha256": "..."
    }
  ],
  "Timestamp": 1681744674356
}

JFrog CLI version

2.28.1

Operating system type and version

Linux

JFrog Artifactory version

No response

JFrog Xray version

No response

[s-geiger-si]

It has been one month since I pushed this issue, is there any additional information that I can provide about this issue?

[fourpastmidnight]

In my particular case, I have a build that is producing all Nuget package files, but the build detects only one artifact as a Nuget package while the rest are detected as Generic. Perhaps it's a different issue--I'm still investigating; but just in case it's related....