I could surely add a line of output to the console such as: “Please replace the content of “dependencies.txt” with the content of “target/apache-iotdb-parent-2.0.0-SNAPSHOT-sbom.txt” to make the build pass this check.”
Chris Von: Xinyu Tan <tanxi...@apache.org> Datum: Montag, 23. September 2024 um 12:16 An: dev@iotdb.apache.org <dev@iotdb.apache.org> Betreff: Re: Automating keeping track of used dependencies? Hi, Chris It's exciting to see how we're going to manage our SBOM, as it heralds the beginnings of establishing control over some of our potential dependency risks. I recommend simply failing the build when adding dependencies without maintaining a list. This makes developers and reviewr more aware of the dependencies introduced by each PR, which is good for the community in the long run. Of course, in order to be developer-friendly, we also need to give developers as much guidance as possible on what to do when build fails. Best --------------- Xinyu Tan On 2024/09/23 08:10:06 Christofer Dutz wrote: > Hi all, > > with legislative initiatives all over the planet ramping up. I think it’s > important that we also do our best to prepare for the future, which is almost > certain to come. > > One thing that will definitely come, is making dependency information (SBOM) > available for releases. > > I’ve already added that to the profile for creating apache-releases. > > However, it would also be good if we would pay a bit more attention to the > dependencies that we add. Both directly and indirectly (If we update a third > party library to a new version, this can pull in new dependencies). > > I’m therefore woking on extending our build to pay attention to this. > > The general idea is to use the data from the sbom generated during the build > and to compare that with data we explicitly maintain in a list. This list > reflects the “dependencies we are aware of”, if someone changes any > dependencies in maven, the sbom will update and then the auto-generated list > will no longer match the one we have on file and do something. > > This “something” could be: > > * that we have a dedicated Jenkins job, that sends out emails if there’s > a mis-match. > * That it fails the build > * Possibly other options that I currently haven’t thought of > > I would personally prefer having this in every build. > > If for example I am working on a feature in a branch and I update > dependencies, I must also update the list we have on file to reflect all > changes. This needs to be checked in with the PR for the build to work. > > Now someone reviewing the PR will also see the changes this PR will have on > the dependencies. > > > What’s your opinion on this? > > Chris >
