feature request: block PR merge when specific thresholds are exceeded

[gxjansen]

Hey James,

Right now the action is advisory only. It posts and updates a PR comment, but the check always passes, so it can't gate a merge through branch protection. It would be useful to optionally fail the check (exit non-zero) when specific thresholds are exceeded, so a repo can mark it as a required status check and block risky dependency changes.

Some form of granularity would be very nice: block on some checks but only warn on others. For example, block when the dependency-count or install-size threshold is exceeded, but keep duplicates and replacements advisory.

A couple of ways that could look:

• Per-check boolean inputs, e.g. fail-on-dependency-count, fail-on-size, fail-on-duplicates, all defaulting to false so current behaviour is unchanged.
• Or a single fail-on input taking a list of check names, e.g. fail-on: dependency-count, size.

Either way, the scanFor* functions would need to return a structured result (which check ran, whether it breached, the message) instead of pushing pre-formatted strings into a shared messages array, so the fail decision can be made per check.

Two open questions:

1. Granularity model: per-check booleans, a single fail-on list
2. Fork / artifact mode: with the comment / artifact / comment-from-artifact split (and the pull_request_target direction in Possibly switch local workflow and (add) examples to use pull_request_target #31), which job should carry the failure? Failing the analysis job seems cleanest, but it interacts with how you're thinking about Possibly switch local workflow and (add) examples to use pull_request_target #31.

[43081j]

good idea! that'd be super useful.

i think we should have a fail-on list in case we add more checks in future.

as for the artifact mode, i think the analysis job should fail and the followup workflow should run regardless of success state of the analysis. so it'd still post the comment etc