You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Granularity model: per-check booleans, a single fail-on list
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:
fail-on-dependency-count,fail-on-size,fail-on-duplicates, all defaulting tofalseso current behaviour is unchanged.fail-oninput 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 sharedmessagesarray, so the fail decision can be made per check.Two open questions:
fail-onlistcomment/artifact/comment-from-artifactsplit (and thepull_request_targetdirection 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.