mirror of
https://github.com/supabase/supabase.git
synced 2026-09-22 13:37:53 +08:00
claude[bot]
0d970b8370
<!-- ccr-slack-attribution --> _Requested by **Jonny Summers-Muir** · [Slack thread](https://supabase.slack.com/archives/C0429V78ACX/p1789496187445649?thread_ts=1789496187.445649&cid=C0429V78ACX)_ ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Chore / CI config fix (Dependabot supply-chain policy). ## What is the current behavior? Dependabot's `npm`-ecosystem pull requests fail our Vercel preview builds. `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3 days), which makes `pnpm install` reject any dependency version published more recently than 3 days ago as a supply-chain safeguard. Dependabot proposes the newest available version the moment it's released, so a Dependabot PR's pinned versions can be — and repeatedly have been — younger than pnpm's 3-day cutoff at the moment CI first runs. Concrete example: branch `dependabot/npm_and_yarn/npm_and_yarn-a6265761c1` (commit `2e988c6`), the `design-system` Vercel preview build fails because `pnpm install` rejects `@antfu/install-pkg@2.1.0` and `@types/d3-selection@3.0.12` under the minimum-release-age policy. This is not a one-off — it recurs across many Dependabot npm PRs (e.g. #50399, #49060, #49013). Note: while investigating, I could not find a pre-existing `package-ecosystem: npm` entry in `.github/dependabot.yml` despite the repo's long history of grouped `npm_and_yarn` Dependabot PRs — meaning the previous npm update cadence (grouping across directories such as `/`, `/apps/studio`, `/e2e/studio`) was apparently running under a GitHub-managed default rather than an explicit, in-repo config. This PR makes that configuration explicit so it's actually possible to attach a `cooldown` to it (see caveats below). ## What is the new behavior? Added an explicit `package-ecosystem: npm` entry to `.github/dependabot.yml`, covering the monorepo's workspace directories (`/`, `/apps/*`, `/packages/*`, `/blocks/*`, `/e2e/*`, matching `pnpm-workspace.yaml`'s `packages:` globs), with: ```yaml cooldown: default-days: 4 ``` A `cooldown` tells Dependabot not to propose a version until it has been out for at least that many days — 4 days here, one day above pnpm's 3-day `minimumReleaseAge` gate to leave margin for scheduling/CI latency. This means Dependabot's proposals are now aligned with pnpm's acceptance window: by the time a PR is opened and CI runs, the version has already cleared the age check, so `pnpm install` no longer rejects it. This fixes the root scheduling mismatch (Dependabot proposes instantly, pnpm requires 3 days of age) rather than weakening the supply-chain check itself — `minimumReleaseAge` and `minimumReleaseAgeExclude` in `pnpm-workspace.yaml` are unchanged. This is a pure CI/dependency-tooling config change with no dependency version bumps, so `pnpm-lock.yaml` did not need to be regenerated. ## Validation - YAML syntax: parsed `.github/dependabot.yml` with `yaml.safe_load` — valid. - pnpm accepts the config: ran `pnpm install --lockfile-only --filter design-system...` (the project named in the failing example) from a clean checkout; it printed `Verifying lockfile against supply-chain policies (3424 entries)... Lockfile passes supply-chain policies`, confirming `pnpm-workspace.yaml`'s `minimumReleaseAge`/`minimumReleaseAgeExclude` config (untouched by this PR) still parses and behaves correctly. - Did not attempt a full monorepo `pnpm install`/lockfile regen: not needed since no dependency versions changed, and a full workspace install is separately blocked in this environment by an unrelated `npm.jsr.io` 403 on `apps/studio`'s `@jsr/std__path` dependency. - Could not validate the new `directories` (plural/glob) `dependabot.yml` field against GitHub's live Dependabot config validator from this sandbox (no network path to it); it is a documented, GA `dependabot.yml` option, but worth a maintainer double-checking the "Insights > Dependency graph > Dependabot" config validation tab once this PR is open. ## Additional context Caveat for a maintainer with org-admin visibility: since no npm entry existed in version control before this PR, it's worth confirming there isn't a separate, org/enterprise-level Dependabot configuration also managing npm updates for this repo (which could now run alongside this new repo-level entry). If one exists, this repo-level entry should take precedence per GitHub's documented behavior, but it's worth a quick check in org Settings, Code security, to rule out duplicate/conflicting scheduling. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01BGhzwT3p6k35oEBJa8ivgH Co-authored-by: Claude <noreply@anthropic.com>
28 lines
967 B
YAML
28 lines
967 B
YAML
version: 2
|
|
updates:
|
|
- package-ecosystem: 'github-actions'
|
|
directory: '/'
|
|
schedule:
|
|
interval: 'weekly'
|
|
cooldown:
|
|
default-days: 7
|
|
# `pnpm-workspace.yaml`'s `minimumReleaseAge: 4320` (3 days) rejects any
|
|
# dependency version younger than 3 days old during `pnpm install`. Without
|
|
# a cooldown, Dependabot proposes the newest release the moment it's
|
|
# published, so its PRs are structurally guaranteed to fail CI/Vercel until
|
|
# the proposed version happens to age past the pnpm gate on its own. This
|
|
# cooldown holds Dependabot's proposals back until they've already cleared
|
|
# (with a one-day margin for scheduling/CI latency) pnpm's minimum release
|
|
# age, so the version pnpm sees is always old enough to be accepted.
|
|
- package-ecosystem: 'npm'
|
|
directories:
|
|
- '/'
|
|
- '/apps/*'
|
|
- '/packages/*'
|
|
- '/blocks/*'
|
|
- '/e2e/*'
|
|
schedule:
|
|
interval: 'weekly'
|
|
cooldown:
|
|
default-days: 4
|