Configure Dependabot for Go modules and actions, so a stale pin is said rather than found (#173)

[iderex]

For #173, the DependencyUpdateToolID class of the supply-chain analysis, which stands at one open alert on this board:

$ gh api 'repos/Flowfin/hub/code-scanning/alerts?state=open' --jq '.[] | select(.rule.id=="DependencyUpdateToolID") | "\(.number)\t\(.state)\t\(.most_recent_instance.message.text)"'
4	open	score is 0: no update tool detected:
Warn: no dependency update tool configurations found
Click Remediation section below to solve this issue

Read 2026-09-07, and the tree agrees with it:

$ git ls-tree -r --name-only origin/main .github | grep -c dependabot
0

What changes

One file, .github/dependabot.yml, watching the two ecosystems this tree carries: Go modules, since go.mod has held a require line since chromedp arrived, and the actions under .github/workflows, every one of which is pinned to a commit. Weekly, one grouped request per ecosystem, held 7 days past a version's publication.

Why this shape and not another. The planning issue for the class, erawright/operations#2175, names this issue among the nineteen it covers and asks every board of the family for "a dependency update configuration with a weekly grouped cadence", so the cadence is the family's rather than one chosen here. The 7-day hold and the grouping of the CodeQL actions are read out of the plugin board's own configuration, which decisions/gate-parity.md names as the target this board is measured against:

$ gh api repos/Flowfin/jellyfin-plugin-sso/contents/.github/dependabot.yml --jq .content | base64 -d | grep -n 'default-days\|codeql-action'
      default-days: 7
      codeql-action:
          - "github/codeql-action*"
      default-days: 7

That configuration's comments are not in this board's language, so the reasons are restated in English in the file rather than copied. Where the group there names only the CodeQL pair, the group here covers the whole ecosystem, which is what the planning issue's "grouped" asks for and which cannot split that pair either.

Two claims in the comments rest on GitHub's options reference, read 2026-09-07. The cooldown "is only available for version updates, not security updates", and the platform applies "a default cooldown period of 3 days to version updates, even when cooldown is not configured", which is why the number is written rather than left to the default. The reference's support table lists both GitHub Actions and Gomod (Go Modules) under default-days, and I have not claimed the SemVer-tier keys for either.

What this file does not do, said in the file: it does not catch a re-pointed tag, because a moved tag has no new publication date for a hold to delay. The hash pins and zizmor's unpinned-uses audit are what cover that class, and they are unchanged here.

The tree already expects this tool: .github/workflows/dco.yml exempts Dependabot's commits from the sign-off it cannot give, and .github/workflows/zizmor.yml skips the SARIF upload on a Dependabot request because that token cannot write security events. Neither needed a change.

What I ran

$ go run . gate
gate examined 14 of 14 legs.
  build                            passed
  test                             passed
  format                           passed
  editorconfig                     passed
  tests-reach-nothing              passed
  no-hardcoded-names               passed
  site-fetches-nothing-outside     passed
  site-links-resolve               passed
  coverage                         passed
  site-declares-its-language       passed
  install-address-is-answered      passed
  colour-stands-off-every-surface  passed
  page-matches-the-token-file      passed
  pr-hygiene                       passed

Run on Windows with the file in the tree. The editorconfig leg is the one that reads a YAML file here, and it passed. Nothing in this tree parses a Dependabot configuration, so whether the file is accepted is read from the platform after the merge: the Insights tab's Dependency graph shows a parse error if there is one, and the first scheduled run is what shows there is not.

What this does not close by itself

The issue's Done-when is the class at zero open alerts on the Security tab, and that reading is produced by the next Scorecard run, which runs on push to main and never on a pull request. So this request carries no closing keyword. Once merged, the alert is re-read from the API after that run and pasted onto #173, and the issue closes on that reading and not on this merge.