Skip to content
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

added folder system as a input and output adapter #54

Merged
merged 4 commits into from
Feb 21, 2025

Conversation

viveksahu26
Copy link
Contributor

@viveksahu26 viveksahu26 commented Feb 17, 2025

closes: #47

This PR add the following changes:

  • Added folder system as a Input Adapter

    • Allows fetching SBOMs stored in a local folder.
    • Supports recursive and non-recursive scanning. (--in-folder-recursive=true)
    • And also add support for flag proceesing mode(parallel or sequential): (--in-folder-processing-mode)
  • Moved shared utility functions from github package to a generic source package, making them reusable across multiple input adapters.

  • Replaced Repo with a more generic Namespace field in the SBOM iterator.

    • GitHub: Uses Namespace = "org/repo"
    • Folder Adapter: Uses Namespace = "folder/subfolder".
  • Add support for Folder as a Output Adapter.

  • To see the testing proof: https://gist.github.com/viveksahu26/badf7ef4c22c8c449d72ec5c5fc85d67

@viveksahu26 viveksahu26 marked this pull request as ready for review February 17, 2025 14:19
@viveksahu26
Copy link
Contributor Author

@riteshnoronha , I have added folder system to support functionalities for input and output adapter. And also performed basic testing.

I have a question about handling deeply nested folders when uploading SBOMs to Interlynk.

For example, in GitHub, if the organization is sigstore and the repository is cosign, the project name becomes sigstore/cosign.

Now, considering a folder structure instead of GitHub, suppose the SBOM file is located at:
temp/temp1/temp2/temp3/temp4/dummy.spdx.json

When uploading this file to Interlynk, what would be its project name?

@viveksahu26 viveksahu26 changed the title added folder system as a input adapter added folder system as a input and output adapter Feb 19, 2025
@viveksahu26 viveksahu26 force-pushed the feature/folder_system branch from e71eda4 to e2f5c9a Compare February 20, 2025 05:07
@viveksahu26
Copy link
Contributor Author

viveksahu26 commented Feb 20, 2025

@riteshnoronha implemented SOLID principle for Folder Adapter. This is really amaazing changes, which refractor in a more modular way: Below is the reason behind Implemention of SOLID principles:

Overview

This refractor Folder input (pkg/source/folder) and output (pkg/target/folder) adapters to align with Single Responsibility Principle(SRP) and Open/Closed Principle (OCP) from SOLID principles. LSP/ISP and DIP are deferred for later.

Why SOLID?

Single Responsibility Principle (SRP) for Folder Input Adapter and Output Adapter

a. Split FolderAdapter Configuration from Logic (SRP)

  • Solution:
    • Separate the FolderAdapter’s configuration state from its behavior to follow the Single Responsibility Principle (SRP).
  • Why:
    • The current FolderAdapter struct mixes configuration (e.g., Recursive, ProcessingMode, FolderPath) with logic (e.g., fetching SBOMs) and violate SRP principle.
  • Changes:
    • Create a FolderConfig struct to hold all configuration data.
    • Update FolderAdapter to use this config struct instead of individual fields.

b. Extract Dry-Run Logic (SRP)

  • Solution:
    • Move DryRun logic into a separate SBOMReporter struct to keep FolderAdapter focused on fetching.
  • Why:
    • The current DryRun mixes SBOM processing with output formatting, violating SRP.
  • Changes:
    • Create a SBOMReporter struct in a new reporter file in the same pkg.

Open/Closed Principle (OCP) for Folder Input Adapter

Introduce Strategy Pattern for Fetch Methods (OCP)

  • Solution:

    • Refactor the fetching logic to follow the Open/Closed Principle, making it extensible without modifying existing code when adding new fetch methods.
  • Why:

    • Currently, adding a new fetch method (e.g., "fetch using parallel or batch") requires modifying FolderAdapter’s FetchSBOMs and FolderIterator’s with new switch cases. This violates OCP because the code isn’t closed to modification.
  • Changes:

    • Define an SBOMFetcher interface for different fetch strategies.
    • Implement concrete fetchers (SequentialFetcher, ParallelFetcher).

Open/Closed Principle (OCP) for Folder Output Adapter

  • Solution:

    • Introduce a strategy pattern for upload modes to make the adapter extensible without modifying existing code.
  • Why:

    • The current UploadSBOMs uses a switch with only UploadSequential implemented, requiring changes to add parallel or batch modes.
  • Changes:

    • Define an SBOMUploader interface.
    • Implement concrete uploaders (SequentialUploader for now).
    • Update FolderAdapter to use the strategy.

Checklist

  • SRP applied to both adapters (config separation, dry-run extraction).
  • OCP applied with fetcher/uploader strategies.
  • LSP/ISP deferred (to be addressed in a future PR).
  • DIP deferred (to be addressed in a future PR).
  • Future work to implement this with Github and Interlynk Adapter.

@riteshnoronha riteshnoronha merged commit 1a9a2d0 into main Feb 21, 2025
1 check passed
@riteshnoronha riteshnoronha deleted the feature/folder_system branch February 21, 2025 05:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Add input/output adapter called folder
2 participants