-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Support for projects with multiple/nested workspaces #35
Comments
I've made an initial proof of concept branch for what the change for this could look like on my own fork here for now https://github.com/MLSTRM/cyclonedx-node-yarn/tree/feature/nested-workspace-traversal - need to rebase past some changes in the last couple of days before I can raise a proper PR if deemed a useful thing to have |
PRs are welcome. Please make sure to follow the contribution guidelines, and add relevant test cases and test-beds |
PR raised + test added, also noticed the old snapshots weren't updated since the license resolution removal so I've updated those at the same time. |
With the v1.0 release candidate being public for some time now, i do not expect any internal refactoring or changes soon. This means, the implementation is ready to be extended. Currently, it should be possible to call the plugin like I still do not understand the need to combine an SBOM over all the workspaces, as this is already done when you called @MLSTRM are you still interested in working on this feature? |
Hi @jkowalleck, apologies for the delayed response. I at least have several projects where the individual workspaces aren't necessarily anything that would be deployed separately, but more as separated modules as part of a larger application - as well as with how I was looking to implement SBOM into my CI/CD process and reporting, a singular file per repo was a much better fit for my aims. |
re: #35 (comment) thanks for the update, @MLSTRM . i wonder how your process would be shaped, if you had individual packages, but just one big BOM for many of these. Could you elaborate on that? Thanks in advance. |
Maybe its more of a consequence of the size of the projects I'm mostly working on, but the generated BOM doesn't end up being that big overall since each sub-package is quite small. A lot of my work is around AWS microservices, where a single repo would be a microservice, but might also expose some other packages for a client library (i.e. for other services to interact with this repo), as well as separation of core processing logic away from AWS lambda specifics, or splitting out storage implementation with DynamoDB vs Postgres vs other storage operator, where each component project may only have a couple of dependencies on its own. Each package isn't necessarily a deployable unit on its own. At the same time, the tooling I'm using (which includes Aqua amongst other things) is also handling BOMs from larger monolith applications that have nearly 1k dependencies (whereas my largest BOM from the microservice side is ~350 dependencies across the workspace of 4 packages), so while the BOM is larger than it would be if you were doing things on a per-package level, its still quite "small" on a wider view. Also the feedback loops I have around audit checks / compliance violations happens at CI/CD time as well as being reported after the fact, and having that attached directly to the repo the violation comes from rather than the specific subpackage makes it easier to address at the right level, as well as cutting down on some of the noise (since hoisted dependencies are then only reported once rather than multiple times). At least for my current use-case, I've been evaluating trivy as a more drop-in language/structure agnostic solution and its serving the requirements quite nicely (at the slight annoyance of it not being so tightly integrated into the build tooling), and I'm fairly happy to write this up just a bad fit potentially where the intended direction of this plugin doesn't quite align with the structure I'm working with. |
Currently this plugin will only resolve the dependencies/components for a single workspace at a time, which can introduce additional complexity/complication when working in a multi-workspace monorepo.
Enhancing the plugin to recursively traverse all nested workspaces is quite a small change and would simplify the usage of this plugin in more complex projects, especially in cases where isolated reporting of BOM information is not required.
The text was updated successfully, but these errors were encountered: