[question] Use art:build-info for consumer of conan packages

[fschoenm]

I'm not sure if this is even possible with the Artifactory extension. I have project that is acting just as a consumer of conan packages but does not create a conan package itself. I'm only using conan install . for getting the dependencies.

I tried to follow the steps in https://github.com/conan-io/conan-extensions/blob/main/extensions/commands/art/README.md, however I only got to step 2a in the description. After conan install I have a JSON file that looks fine but I cannot conan upload because my consumer is not a conan package itself. conan art:build-info create then doesn't generate anything useful, just an almost empty JSON struct:

{
    "version": "1.0.1",
    "name": "application-name",
    "number": "129",
    "agent": {},
    "started": "2024-01-04T10:24:14.908+0100",
    "buildAgent": {
        "name": "conan",
        "version": "2.0.16"
    },
    "modules": []
}

Nevertheless, I'd like to store the dependencies in the build info. My conan packages are stored on the same Artifactory (if that's a requirement) but just having the names for now would also be fine.

Is what I want even possible?

[danimtb]

Hi @fschoenm,

Thanks for your report.

We can take a look if the install JSON output is suitable to generate a build info. However, I am not sure about the use case, as the build info is normally generated from packages that you are actually building. In your example, you are just installing the packages, so I am not sure how the build info would be useful in that case. Maybe I need some more context.

Also, regarding the conan upload, we are working on the build-info workflow to avoid this need in some cases. It will help to smooth the process and cover some other use cases.

Thanks a lot for the feedback, it helps us to improve the extension commands for Artifactory 😄

[fschoenm]

@danimtb Thanks for the answer.

The context is this:

• We have a C++ application that uses Conan packages as a consumer. It is not a Conan package itself but gets distributed to customers. I build it with conan build (or manually with CMake or an IDE if required).
• All our dependencies are Conan packages though and we have a Conan remote on Artifactory.
• The final artifacts (executable, documentation, ...) of the application are stored on a generic Artifactory repo, not a Conan remote. I'd like to add a build info though referencing the (Conan) dependencies.

Seems like a common use case to me but maybe you have other ideas how we could handle that?

[h-2]

Seems like a common use case to me but maybe you have other ideas how we could handle that?

This is pretty much exactly my usecase, I think. We have an internal artifactory server that has all the dependencies required for some of our tools (which themselves are not conan packages). Uploading and downloading dependencies works, but the artifactory WebUI shows nothing in the build tab, so I can't easily see when a binary build was uploaded, for which architectures it is available, etc.
I thought art:build_info was necessary to be able to provide this information, but I am less and less sure about that 🤔

[h-2]

To be clear, the only thing that I need, is the following:
When clicking on a package in artifactory, it should show the different artifacts for that package, when they were uploaded and by whome; for which platform they were built (os, arch, compiler, stdlib, cxx_standard).

Do I need artifactory tooling for that? Isn't that information available already?

[danwalshnitro]

I'm currently looking at the same thing. We have a C++ app that depends on conan packages in Artifactory and we want to be able to get an xray report for each build reporting any vulnerabilities in the dependencies.

[danimtb]

Hi @danwalshnitro

Thanks a lot for the comment and for the tentative PR to solve the issue.
We have taken a look at the issue and found that we had the changes ongoing in a different PR. I have isolated the changes to fix this issue at #127, please try the command with the new --add-cached-nodes flag to include nodes installed in the build info.

I have tested it and can confirm that it produces the XRay report you asked for 😄
Please, let me know what you think!

Also @fschoenm, I think the PR proposed covers your use case as well 😃