Add Dependabot configuration

Start with the requested .github/dependabot.yml, then inspect Dockerfile, the four files under .github/workflows/, and the repository's package manager metadata. Confirm Dependabot is not paused before validation. Done means the configuration is merged and Dependabot opens at least one reviewable pull request; the issue notes that this work is internal and does not accept external contributions.

There is no .github/dependabot.yml in the repo. Every version bump is manual, which is why the base image drifts for weeks at a time and why our GitHub Actions SHA pins only move when someone notices.

Add a config covering three ecosystems:

• docker on /, so the FROM tag in Dockerfile gets a PR when a newer Amazon Linux 2023 snapshot ships. This is the one that removes the recurring manual bump.
• github-actions on /, so the SHA pins across the four workflows in .github/workflows/ stay current.
• npm on /, grouped, so Dependabot takes over from our own periodic sweeps rather than just backstopping them.

Validation notes

I checked the open questions against dependabot-core and the live registry so the implementer does not have to re-derive them.

pnpm is fine. npm is the correct package-ecosystem value for pnpm. PNPMPackageManager::SUPPORTED_VERSIONS covers pnpm 7 through 12, so our 11.9.0 is in range, and the updater activates the exact version from our packageManager field through corepack, so there is no skew with what CI installs. Lockfile v9 is parsed via @pnpm/lockfile-file. Workspaces and catalogs are both handled, though we use no catalogs.

minimumReleaseAge does need cooldown. I reproduced the interaction: with minimumReleaseAge set and a range whose only match is too new, pnpm fails with ERR_PNPM_NO_MATURE_MATCHING_VERSION, which kills Dependabot's lockfile step so the PR never opens. Dependabot already applies a 3-day cooldown to version updates by default, which more than covers our 1440 minutes, but set it explicitly so the margin is visible in the config. Worth knowing that cooldown applies to version updates only, not to security-updates.

Docker needs no ECR credentials. The credentials finder only takes the AWS SDK path for *.dkr.ecr.<region>.amazonaws.com. public.ecr.aws is treated as a plain public registry: I confirmed an anonymous token followed by HTTP 200 on /v2/amazonlinux/amazonlinux/tags/list, 768 tags. No registries: block and no repo secrets.

Our tag shape compares correctly. 2023.12.20260803.3 is classified :year_month, and candidates have to match on format, precision, and suffix, so the -minimal, -amd64, and 5-segment variants are filtered out. Segments compare numerically, so 2023.9.* does not beat 2023.12.*.

Interval decisions

Settled rather than left to the implementer.

docker daily. It is a single ungrouped dependency, so Dependabot only opens or replaces a PR when a new snapshot actually ships. The median gap between AL2023 snapshots is 7 days, with recent ones at 3 to 5, so daily checking costs nothing and cuts worst-case lag from two weeks to one day. This needs an explicit cooldown.default-days: 1, otherwise the 3-day default cancels out the tighter interval. Docker supports default-days but not the semver-*-days keys.

npm weekly, not daily. group_update_refreshing.rb has three refresh paths, and the one that fires when target versions change closes the open group PR and opens a replacement. For a minor-and-patch group spanning ~130 dependencies that happens on nearly every run, so a daily interval would mean a near-daily cycle of superseded PRs, each burning a full CI run plus two docker builds and resetting any review in progress. Weekly keeps one PR stable for most of the week, and still beats the two-to-four-week cadence our manual sweeps actually ran at.

github-actions weekly and grouped. actions/checkout is pinned in all four workflows, so without a group a single bump produces four PRs.

Majors ungrouped. Grouping them means one breaking bump blocks every other major in the same PR, which is what Update dependencies and upgrade react-router to v8 (#1851) would have been. Let majors arrive individually and raise open-pull-requests-limit to absorb them.

Monday scheduling in America/Chicago so the queue lands when someone is around to clear it. This matters more than usual here, see the acceptance note below.

Starting config

version: 2
updates:
  - package-ecosystem: docker
    directory: /
    schedule:
      interval: daily
    cooldown:
      default-days: 1
    open-pull-requests-limit: 2

  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly
      day: monday
    open-pull-requests-limit: 3
    groups:
      actions:
        patterns: ["*"]

  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
      day: monday
      timezone: America/Chicago
    open-pull-requests-limit: 8
    cooldown:
      default-days: 2
    groups:
      minor-and-patch:
        update-types: [minor, patch]

Out of scope

Two things stay manual and should not be folded in here:

• ENV NODE_VERSION in Dockerfile is invisible to the docker ecosystem, which only reads FROM.
• The overrides block in pnpm-workspace.yaml is not parsed as dependencies, so stale entries still need pruning by hand.

Acceptance

A merged .github/dependabot.yml, and Dependabot opening at least one PR we can look at.

Before debugging the config, confirm Dependabot is not paused. gh api repos/aws/graph-explorer/automated-security-fixes currently returns {"enabled":true,"paused":true}. GitHub pauses Dependabot when maintainers stop interacting with its PRs, and it is resumed from Insights, then Dependency graph, then Dependabot.

[!IMPORTANT]
Internal only — this issue is maintained by the core team and is not accepting external contributions.