Closes #2233 — the alert-consuming half of #2229. #2235 removed `.github/dependabot.yml`, ending Dependabot's version-update PRs; this ends its security-update PRs and replaces them with a daily sweep that turns the alerts into ordinary board items. - `scripts/dependabot-alerts.mjs` groups alerts by `(package, manifest_path, first_patched_version)` — one issue per BUMP, not per advisory — re-checks each vulnerable range against `v2/main`'s own lockfile before filing, and keys idempotency on a marker comment naming every GHSA the issue covers. - `.github/workflows/dependabot-alerts.yml` runs it daily and on `workflow_dispatch`, with `vulnerability-alerts: read`. - `semver` is declared at the repo root, per Dependency placement: `scripts/` is root-owned code with no manifest of its own. - The sibling `dependency-refresh` comments no longer claim security updates are unaffected, and AGENTS.md gains the flow both halves now follow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013H6Cew3KB3jVmQ5x4Dq1sq Signed-off-by: cliffhall <cliff@futurescale.com>
89 lines
4.1 KiB
YAML
89 lines
4.1 KiB
YAML
# Dependabot alert sweep (#2233), the alert-consuming half of #2229.
|
|
#
|
|
# Dependabot's SECURITY-update PRs are turned off for this repo; its ALERTS are
|
|
# left on. Those are two independent settings, and this workflow depends on the
|
|
# split: it reads the alerts and turns them into ordinary board-tracked issues,
|
|
# so the fix is written by hand against `v2/main` like any other work.
|
|
#
|
|
# alert -> this sweep -> issue (labeled, milestoned, boarded) -> maintainer PR -> v2/main
|
|
#
|
|
# It is a SCHEDULE, not an event handler, because there is no `dependabot_alert`
|
|
# workflow trigger — that is a webhook event only. Daily is deliberate: with
|
|
# security PRs off there is no mergeable-against-`main` artifact and no window to
|
|
# race, so the merge guard #2060 needed has no analogue here. What replaces it is
|
|
# a precondition inside the script: `automated-security-fixes` is a repo SETTING
|
|
# and can be switched back on from the UI without a commit, so the sweep asserts
|
|
# it is still disabled and fails loudly if it is not.
|
|
#
|
|
# ⚠️ GitHub computes the dependency graph, and therefore every alert, from the
|
|
# DEFAULT branch (`main`), while we ship from `v2/main`. Two consequences:
|
|
#
|
|
# * An alert is re-checked against `v2/main`'s own lockfile before an issue is
|
|
# filed — hence the `ref: v2/main` checkout below. An alert whose vulnerable
|
|
# range no longer matches is already fixed on the branch we ship from and is
|
|
# waiting on a milestone merge to close, so it is skipped silently.
|
|
# * A vulnerable dependency introduced on `v2/main` and not yet merged to
|
|
# `main` produces NO alert at all. No approach that consumes GitHub's alerts
|
|
# avoids that. The release-time `npm audit fix` from #2231 is a second signal
|
|
# that partially covers it; a scheduled `npm audit --audit-level=high` over
|
|
# `v2/main`'s lockfiles would close it fully and is a separable follow-up.
|
|
#
|
|
# `vulnerability-alerts: read` is the one non-default permission, and
|
|
# `GITHUB_TOKEN` supports it — no PAT is needed to read the alerts themselves.
|
|
# Two side steps are outside its reach, and `PROJECT_TOKEN` is what covers them
|
|
# when it exists:
|
|
#
|
|
# * Writing the board card, since board #28 is an ORG project
|
|
# (`organization projects: write`). Absent, the issue is still filed labeled
|
|
# and milestoned and the next `/issue-triage` sweep boards it.
|
|
# * Reading back `automated-security-fixes`, which needs `administration: read`
|
|
# — a permission `permissions:` has no key for, so `GITHUB_TOKEN` can never
|
|
# have it. Absent, that assertion is reported as UNVERIFIED rather than
|
|
# failing the run; an explicit `enabled: true` still fails it.
|
|
#
|
|
# Nothing the sweep exists to do is skipped for want of that secret.
|
|
#
|
|
# The version-update half of #2229 is the sibling `dependency-refresh.yml`.
|
|
name: Dependabot Alert Sweep
|
|
|
|
on:
|
|
schedule:
|
|
- cron: "17 6 * * *" # 06:17 UTC daily; alerts are not minute-sensitive
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: read
|
|
issues: write
|
|
vulnerability-alerts: read
|
|
|
|
jobs:
|
|
alert-sweep:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- name: Checkout v2/main
|
|
uses: actions/checkout@v7
|
|
with:
|
|
ref: v2/main
|
|
|
|
- name: Setup Node.js
|
|
uses: actions/setup-node@v7
|
|
with:
|
|
node-version: "22.x"
|
|
cache: "npm"
|
|
|
|
# Root install only, and no lifecycle scripts. The sweep's one dependency
|
|
# is `semver`; it reads every lockfile as JSON and never needs a client's
|
|
# tree on disk, so the postinstall cascade into `clients/*` that
|
|
# `dependency-refresh.yml` genuinely needs (it shells out to
|
|
# `npm outdated` in each) would be minutes of nothing here.
|
|
- name: Install root dependencies
|
|
run: npm ci --ignore-scripts
|
|
|
|
- name: Run the Dependabot alert sweep
|
|
run: node scripts/dependabot-alerts.mjs
|
|
env:
|
|
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
GITHUB_REPOSITORY: ${{ github.repository }}
|
|
# Optional: an org-project PAT with `organization projects: write`.
|
|
# Absent, the issue is filed unboarded and triage picks it up.
|
|
PROJECT_TOKEN: ${{ secrets.PROJECT_TOKEN }}
|