Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: hiero-hackers/analytics/.coderabbit.yml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe change adds models and helpers to retrieve dependency-graph SBOM data for repositories, aggregate results across an organization with retries, and measure coverage with a standalone script. ChangesSBOM coverage collection
Priority: ➖ Normal Merge Risk: 🟡 Moderate · up to Some repositories with inaccessible SBOMs may be reported as having disabled dependency graphs, making the coverage results unreliable. Resolve or explicitly accept that ambiguity before merging. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Linked Issues checkExplanation For the staged SBOM ingestion objective in Resolution Treat HTTP 403 as
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: fb0710e0-e9e4-45b7-8111-3f1c2d784f57
📒 Files selected for processing (5)
measure_sbom_coverage.pysrc/hiero_analytics/data/dependency_repo_map.yamlsrc/hiero_analytics/data_sources/github_rest.pysrc/hiero_analytics/data_sources/models.pytests/data_sources/test_github_rest.py
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review.
…hiero-hackers#338) First slice of hiero-hackers#338 (repo dependency network chart) -- data layer only, per the design agreed with exploreriii: measure real SBOM coverage before building the resolution heuristic or the chart around a guess. - models.py: DependencyManifestRecord (one parsed SBOM package, purl-based ecosystem+name+version, not the raw SPDX name field) and SbomCoverageRecord (per-repo fetch outcome: ok/disabled/error -- kept distinct from the package list itself, so 'no edges' is distinguishable from 'no data', per the issue's coverage-honesty requirement). - github_rest.py: fetch_repo_sbom (REST SBOM endpoint, 403/404 -> disabled mirroring has_codeowners_file's exact contract, any other error -> status='error' rather than raising or silently dropping), _parse_purl (percent-decoded, handles npm scopes/Maven groupIds/Cargo/PyPI/Go), fetch_org_sbom_data (org-wide fan-out via fetch_all_with_retry, always exactly one coverage row per input repo). - data/dependency_repo_map.yaml: the curated-override file, following affiliations.yaml's '# manual' convention but explicitly documented as a different *kind* of file -- corrections-only, not a comprehensive regenerated map. Empty by design until real resolution data exists. - measure_sbom_coverage.py: standalone script (not a registered pipeline yet -- that's gated on this measurement) to answer the actual open question: how many hiero-ledger repos have a readable SBOM at all. Bug caught before committing: the first working version of _parse_purl didn't percent-decode the namespace/name segment, so a scoped npm package like '@org/pkg' parsed back out as the literal '%40org/pkg'. Caught by testing against a realistic synthetic purl, not by inspection. No resolution heuristic, no chart, no pipeline registration yet -- those depend on what the coverage script finds when run against real hiero-ledger data. Deliberately small first slice, per the PR-split plan agreed in the design comment. Verified: 738 passed, 95.36% coverage, ruff clean. Data-source and fan-out logic verified interactively against realistic synthetic SBOM payloads (SPDX shape, documentDescribes root-exclusion, mixed ok/disabled/error repos) before writing the formal tests. Signed-off-by: iron-prog <dt915725@gmail.com>
f8bd032 to
848d2ca
Compare
Signed-off-by: iron-prog <dt915725@gmail.com>
phillip-nyinomujuni
left a comment
There was a problem hiding this comment.
A few small questions and one thing I wanted to double check on the SBOM status logic nothing blocking, just curious about the reasoning. Nice clean addition overall, especially the dataclass docstrings.
Signed-off-by: iron-prog <dt915725@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: 397ac5dc-33cb-4d20-821f-8be20f110f9c
📒 Files selected for processing (2)
src/hiero_analytics/data_sources/github_rest.pysrc/hiero_analytics/data_sources/models.py
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
Signed-off-by: iron-prog <dt915725@gmail.com>
📊 Dashboard previewThe dashboard was built for this PR. ➡️ Download
|
exploreriii
left a comment
There was a problem hiding this comment.
What do the results show? what is your opinion should we proceed or not?
Other than that suggest slightly tidying up the code, thank you
|
The SBOM coverage experiment succeeded and provides enough real data to justify the next measurement: dependency resolution. |
Signed-off-by: iron-prog <dt915725@gmail.com>
9064a4d to
ed55e51
Compare
|
You forgot to lint the code please before requesting a review @iron-prog |
Sorry for this one |
Description
Add the first data-layer slice for the repository dependency network proposed in #338.
This slice measures real SBOM availability across the
hiero-ledgerorganization before introducing dependency resolution heuristics or visualization.What this PR adds
ok,disabled, anderroroutcomesReal SBOM coverage
The coverage measurement was run against the real
hiero-ledgerorganization:Readable SBOM coverage:
41 / 44 = 93.18%
Ecosystem breakdown:
The current measurement establishes SBOM availability and package ingestion. It does not yet measure how many dependencies resolve to other
hiero-ledgerrepositories. That resolution measurement will be part of the next slice.Related issue(s)
Fixes #338
Notes for reviewer
This PR intentionally stops at the data/measurement layer.
The real-org measurement confirms that SBOM data is available for the large majority of
hiero-ledgerrepositories, with 35,263 dependency records available for further analysis.The next slice can therefore focus on dependency resolution and determine how much of this data can be mapped to other repositories in the organization before introducing the dependency network/chart layer.
One bug found during development was that percent-encoded purl namespaces were not decoded correctly (e.g. scoped npm packages). This is covered by the purl parsing tests.
Verification
uv run pytestuv run ruff check src testshiero-ledgerSBOM coverage measurementok/disabled/erroroutcomes and root-package exclusionChecklist
/assignbefore starting (see contributing guideuv run pytestanduv run ruff check src testspass locallysrc/layout)git commit -S -s