Enforce severity and license gates in dependency-review workflow

[AndreasIgel]

Upstream counterpart of fork PR AndreasIgel#7. Head branch: AndreasIgel/simple-builders-fork:feature/160-dependency-review-gates → base java-helpers/simple-builders:main.

Summary

Turns the Dependency Review check from advisory-only into an enforced gate.

Fixes #160

.github/workflows/dependency-review.yml previously had the enforcement options commented out, so a PR adding a vulnerable or copyleft-licensed dependency would only get a comment, never fail. Enabled:

fail-on-severity: high
deny-licenses: GPL-1.0-or-later, GPL-2.0-or-later, GPL-3.0-or-later, LGPL-2.0-or-later, LGPL-2.1-or-later, LGPL-3.0-or-later, AGPL-3.0-or-later
retry-on-snapshot-warnings: true

License denylist targets the copyleft families incompatible with this MIT project; retry-on-snapshot-warnings avoids spurious failures when the dependency-submission snapshot lags right after a push.

Validation

• actionlint passes.
• Workflow-only change; no Maven impact.

Note: this action requires the fork's Dependency graph to be enabled (Settings → Security & analysis). Until then the dependency-review check fails with "Dependency graph is not enabled" — a fork setting, unrelated to this change. The other red checks (build) are the fork's missing SONAR_TOKEN/CODECOV_TOKEN.

Fork PR support (added)

A plain pull_request run from a fork gets a read-only GITHUB_TOKEN, so comment-summary-in-pr: always could not post its summary on external PRs (##[warning]Unable to write summary to pull-request ...). The check still ran, but maintainers never saw the review comment on fork PRs.

Fixed by switching the trigger to pull_request_target, which runs in the base-repo context with a read/write token so the summary posts on fork PRs too. This is safe here because dependency-review-action never checks out or executes PR-supplied code — it only diffs the PR's base/head via the GitHub dependency-graph/advisory API. The Checkout repository step was removed (it was unused; the action needs no checkout without a config-file), guaranteeing no untrusted code runs with the elevated token.

On unrecognized licenses (review question)

With a deny-list (deny-licenses), a dependency whose license can't be detected is reported but does not fail the check (per the action docs: "If we can't detect the license for a dependency we will inform you, but the action won't fail."). So unrecognized licenses do not break the build here. Switching to allow-licenses would be the opposite — it fails on anything not in the allow-list, including unknown licenses — so the deny-list is intentionally kept. deny-licenses is marked deprecated upstream; if it is ever removed, the migration is to exempt specific packages via allow-dependencies-licenses, not to adopt allow-licenses.

Maintainer TODOs

• Enable Dependency graph under Settings → Code security (repo). dependency-review-action needs it; while it is disabled the Dependency Review check fails/does nothing regardless of this PR. Once enabled, fail-on-severity: high + deny-licenses take effect on every PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[AndreasIgel]

What about licenses not recognized, we have some here which are Not recognized right?

[AndreasIgel]

Answered here + fixed the fork limitation.

Unrecognized licenses: with a deny-list (deny-licenses), a dependency whose license can't be detected is reported but does not fail the check — from the action docs: "If we can't detect the license for a dependency we will inform you, but the action won't fail." So the ones you're seeing as Not recognized will not break the build. (Switching to allow-licenses would be worse: it fails on anything not in the allow-list, including unknown licenses — so I deliberately keep the deny-list. Note deny-licenses is marked deprecated upstream; if it's ever removed, the right migration is allow-dependencies-licenses to exempt specific packages, not allow-licenses.)

Separately, I noticed the Dependency Review check couldn't post its summary comment on fork PRs (fork pull_request runs get a read-only token). Fixed by switching the trigger to pull_request_target (safe: the action only diffs base/head via the dependency-graph API and never runs PR code; the unused checkout step was removed). Pushed to feature/160-dependency-review-gates.