Say whether the dependency review had anything to review (#62)

[iderex]

One clause of #62 asks that every job whose context the parity document keeps
prints whether it had work to do. The dependency-review job did not, and this
is that clause for that job. It closes nothing: the rest of #62 is a comparison
against a required set that does not exist yet, and a fork route that has not
been walked.

What was wrong

Success from that job reports two different things with one tick. Either a
manifest changed and carried no advisory, or no manifest changed at all and
there was nothing to compare. The second is the ordinary case on this board,
and on #129, which changed no manifest, the job printed an empty group and no
sentence saying which of the two it was:

gh pr view 129 --json files --jq '.files[].path'
.github/workflows/build.yml
.github/workflows/codeql.yml
.github/workflows/headless.yml
CONTRIBUTING.md
docs/decisions/0017-what-the-gate-reads-of-an-experiment.md

A reader is then told the dependencies were reviewed when nothing was submitted
for review.

What this does

A step before the action, because the action decides advisories and this says
what it was handed. It lists the files this repository declares a dependency
graph in, compares the merge commit against the base the change would land on,
and prints which of the two cases the run is. It runs before rather than after
so the sentence reaches the log whichever way the review goes.

The pathspecs are one array read by both commands, so the set the step reports
and the set it compares cannot drift apart. They match at any depth, so a
second module arriving under this root is read rather than missed.

The checkout takes two commits rather than one. That is what makes the first
parent of the merge commit available to compare against, and nothing else in
the job reads history.

What this does not do

It does not make the action itself say anything. Whether a manifest carried an
advisory is still the action's answer alone, and this step cannot see inside it.

It reads the manifests git tracks rather than every ecosystem the action
understands. This repository carries one module and no other manifest, which
the first command below prints, so today the two sets are the same. They would
not be on a tree that gained a manifest in another ecosystem.

What I ran

Both branches of the new step, against real commit pairs in this repository
rather than against invented ones. The empty case, over the two most recent
commits on the default branch:

graph=(':(glob)**/go.mod' ':(glob)**/go.sum')
git ls-files -- "${graph[@]}"
go.mod
git diff --name-only 896d9a8 fa3ca26 -- "${graph[@]}"
(no output)

The non-empty case, over the commit that created the module:

git diff --name-only 204903b^ 204903b -- "${graph[@]}"
go.mod

The gate the contributing guide names, at 6af5f87:

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
(no output)
go test -count=1 ./cmd/... ./internal/...
ok  github.com/Flowfin/lab/cmd/contexts     2.798s
ok  github.com/Flowfin/lab/cmd/lab  3.327s
ok  github.com/Flowfin/lab/cmd/pullrequest  1.931s
ok  github.com/Flowfin/lab/internal/check   4.152s
ok  github.com/Flowfin/lab/internal/contexts        2.438s
ok  github.com/Flowfin/lab/internal/hardware        1.209s
ok  github.com/Flowfin/lab/internal/invariants      3.158s
ok  github.com/Flowfin/lab/internal/prose   2.774s
ok  github.com/Flowfin/lab/internal/pullrequest     2.001s

The check-name comparison, since this touches a workflow file, with the
ruleset's answer of no required context fed to it:

go run ./cmd/contexts < /dev/null
compared the required contexts against the check names this tree declares
  required by the ruleset: 0
  declared by the workflows: 25
  written down as deliberately absent: 25
0 refusal(s), 3 note(s)

No job is added and no check name changes, so the declared set is the same 25.

Reading

No second person has read this change. The ruleset on the default branch
requires no approving review, so the evidence above stands in place of one
rather than beside one:

gh api repos/Flowfin/lab/rules/branches/main \
  --jq '.[] | select(.type=="pull_request")
        | .parameters.required_approving_review_count'
0

The part of this that no local command can prove is the comparison against the
first parent, because a merge commit only exists on the platform. This pull
request is the first run of it, and its own dependency-review log is the
evidence.

An earlier version of this body quoted a different file list for #129. It was
not what the command prints, and the list above is.