Skip to content

dependency-review posts benign 'missing snapshots' warning; submit Maven dependency snapshots #212

Closed

Description

@AndreasIgel

Problem

The dependency-review check passes (green ✅) but posts a "Snapshot Warnings: No snapshots were found for the head SHA ..." block in the PR comment on every PR.

Root cause: this Maven project's dependency graph is populated only by GitHub's static pom.xml parsing (manifest-based). No dependency submission snapshots exist, so dependency-review-action emits the snapshot warning even though it falls back to the manifest graph and still passes.

The retry-on-snapshot-warnings: true option added in #182 is counterproductive here: with no submission workflow, it makes every run retry for ~2 min waiting for a snapshot that never arrives, then proceeds with the warning anyway.

Fix

  • Add a dependency-submission.yml workflow (Maven dependency submission action) on push to main, which submits the full transitive dependency snapshot to the dependency graph. This improves vulnerability detection (transitive deps, not just declared ones) and gives main real snapshot data.
  • Remove retry-on-snapshot-warnings from dependency-review.yml.
  • Document that the head-SHA snapshot warning on fork PRs is expected/benign — a fork PR head cannot get a submitted snapshot without building untrusted fork code with a write token, which we deliberately avoid.

Follow-up to #160 / #182.

Activity

  1. AndreasIgel commented on Jul 26, 2026

    @AndreasIgel
    CollaboratorAuthor

    Corrected approach: the Maven dependency-submission idea won't fix this. Submitting a snapshot on main cannot produce a snapshot for a fork PR's head SHA, and one can't be produced for the fork head without building untrusted fork code with a write token — so the "No snapshots were found for the head SHA" warning would persist on PRs regardless.

    The real fix (in #216) is to configure the action's comment-summary-in-pr: on-failure. The summary comment (which is where the snapshot warning shows up) is then only posted when the review actually fails on a vulnerability/denied license; on clean PRs no comment is created, so the benign warning no longer appears on PRs. The check still runs and still fails on real issues, and the warning is still visible in the Actions run log. This is the standard OSS approach (GitHub's starter workflow defaults this option to never).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions