• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

dennisdoomen / packageguard / 35223164688
82%
main: 82%

Build:
Build:
LAST BUILD BRANCH: claude/issue-212-9f0c6c
DEFAULT BRANCH: main
Ran 17 Sep 2026 12:56PM UTC
Jobs 1
Files 90
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

17 Sep 2026 12:15PM UTC coverage: 81.671%. First build
35223164688

push

github

web-flow
Add a packageguard explain command showing dependency paths and verdict rationale (#256)

* Track which rule and configuration file decided each package's allow/deny verdict

Allow/deny checks only ever returned a bare true/false, so nothing in the
codebase could say which specific rule made that decision, or which of
several hierarchical configuration files introduced it. That information is
needed to explain a policy verdict to a user instead of just stating it.

Give the allow and deny lists an evaluation path that returns the matched
rule's reason text alongside the same pass/fail outcome the existing
boolean checks already produce, and have those checks delegate to it so
behavior is unchanged. Package rules now carry the configuration file they
were parsed from, and license/feed rules are looked up in a per-value map
populated the same way, so the reason can also name the file it came from
when the rule was loaded from a discovered configuration file, keeping the
first file that introduced a given license or feed value in the event of
duplicates across layers. Building that per-rule provenance requires
merging each configuration file's rules into the effective policy one file
at a time, rather than collapsing all raw settings together before
converting them.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Resolve NuGet dependency chains from the restored lock file

Nothing captured which direct dependencies pull a given transitive package
into a project, or what version range each requester along the way asked
for. That's the one piece of data most needed when a violation lands on a
package nobody directly referenced, and the restored lock file already
contains it.

Walk the lock file's project-to-package graph, breadth-first, from each
direct dependency down to a target package, keeping the version range
requested at each hop so the resolved version can be explained alongside
the path. A multi-targeted project repeats the same direct... (continued)

2128 of 2888 branches covered (73.68%)

Branch coverage included in aggregate %.

323 of 527 new or added lines in 15 files covered. (61.29%)

6730 of 7958 relevant lines covered (84.57%)

1734.69 hits per line

Uncovered Changes

Lines Coverage ∆ File
174
10.49
Src/PackageGuard/ExplainCommand.cs
9
88.0
Src/PackageGuard.Core/ProjectAnalyzer.cs
7
0.0
Src/PackageGuard/Program.cs
6
87.72
Src/PackageGuard.Core/CSharp/NuGetDependencyPathFinder.cs
3
0.0
Src/PackageGuard/AnalyzeCommand.cs
3
92.86
Src/PackageGuard/ConfigurationLoader.cs
1
96.83
Src/PackageGuard.Core/Policy/AllowList.cs
1
96.97
Src/PackageGuard/ExplainCommandSettings.cs
Jobs
ID Job ID Ran Files Coverage
1 35223164688.1 17 Sep 2026 12:56PM UTC 90
81.67
GitHub Action Run
Source Files on build 35223164688
  • Tree
  • List 90
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #35223164688
  • 3f679e23 on github
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc