You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our setup, there's a step where we download a non-conan artifact from Artifactory via JFrog CLI, and then re-export it as a conan package via conan export-pkg. There is additionally some dependency managment via conan itself, so the dependency managment already profivded by conan art:build-info create is something that shouldn't get lost.
We have full control over the module name that the JFrog CLI is using for the download (we end up with a module having only dependencies, but no artifacts), but we have no control over (nor are we certain it's supposed to be something stable!) the module IDs assigned by conan art:build-info create.
What we are trying to achieve, is to embed the dependency graph we do have for those artifacts to the dependency graph of the module that has been managed by conan art:build-info create.
The end goal for us is to have a full software bill of materials for the final conan package and even its consumers at the time its published in Artifactory. Even though I'm not quite certain if picking JFrog Build Info is the right tool to track the SBOM, or if we should rather just stick to using it only for attributing build meta data and keep the SBOM as an artifact in a different format. (Well knowing that it will have to be glued together manually at some later point.)
A possible solution might be a variation of conan art:build-info append that permits to slice a specific module ID expressing the re-packaged entity as a dependency of a specific conan reference (which may also be generalized to be just any module ID - if the module ID generation schema is documented and frozen).
This does involve:
transforming the re-packaged module itself from "top level module" into a dependency
merging transitive dependencies into the dependency list of the conan package
extending all requestedBy chains of all merged entities that did previously point to the original module to now extend to the re-packed conan package module.
The existing conan art:build-info append command can so far only express bundles of modules, but not chains.
https://github.com/jfrog/build-info-go provides decent tooling for importing the dependency graph from a single package manager into a corresponding build_info description, but there is no functionality in the command line interface for merging build_info files, let alone patching dependencies. The functionality to merge build_info files in the first place is pretty much conan exclusive.
The text was updated successfully, but these errors were encountered:
Ext3h
changed the title
Merging dependencies from 3rd party build info module into module re-packaged with conan
Merging dependencies from 3rd party JFrog build info module into module re-packaged with conan
Jan 8, 2025
While I get an idea of your set up, I think it will be more illustrating if you could provide an example of the whole flow step by step so we can fully understand the issue.
Some questions:
Does the non-conan artifact that you export-pkg have conan dependencies?
Does the non-conan artifact already have a build info associated?
Do you want to merge the non-conan artifact's build info with a conan generated build info? Where is that conan-generated build info coming from?
I hope that with the example you can provide, I can get this questions answered to further assist you with this issue. Thank you!
danimtb
changed the title
Merging dependencies from 3rd party JFrog build info module into module re-packaged with conan
[feature request] Merging dependencies from 3rd party JFrog build info module into module re-packaged with conan
Jan 10, 2025
In our setup, there's a step where we download a non-conan artifact from Artifactory via JFrog CLI, and then re-export it as a conan package via
conan export-pkg
. There is additionally some dependency managment via conan itself, so the dependency managment already profivded byconan art:build-info create
is something that shouldn't get lost.We have full control over the module name that the JFrog CLI is using for the download (we end up with a module having only dependencies, but no artifacts), but we have no control over (nor are we certain it's supposed to be something stable!) the module IDs assigned by
conan art:build-info create
.What we are trying to achieve, is to embed the dependency graph we do have for those artifacts to the dependency graph of the module that has been managed by
conan art:build-info create
.The end goal for us is to have a full software bill of materials for the final conan package and even its consumers at the time its published in Artifactory. Even though I'm not quite certain if picking JFrog Build Info is the right tool to track the SBOM, or if we should rather just stick to using it only for attributing build meta data and keep the SBOM as an artifact in a different format. (Well knowing that it will have to be glued together manually at some later point.)
A possible solution might be a variation of
conan art:build-info append
that permits to slice a specific module ID expressing the re-packaged entity as a dependency of a specific conan reference (which may also be generalized to be just any module ID - if the module ID generation schema is documented and frozen).This does involve:
requestedBy
chains of all merged entities that did previously point to the original module to now extend to the re-packed conan package module.The existing
conan art:build-info append
command can so far only express bundles of modules, but not chains.https://github.com/jfrog/build-info-go provides decent tooling for importing the dependency graph from a single package manager into a corresponding
build_info
description, but there is no functionality in the command line interface for mergingbuild_info
files, let alone patching dependencies. The functionality to mergebuild_info
files in the first place is pretty much conan exclusive.The text was updated successfully, but these errors were encountered: