version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      security-patches:
        applies-to: security-updates
        update-types:
          - "patch"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 3
    groups:
      # init, analyze and upload-sarif are one release pinned in three places.
      # Bumped separately, a run mixes two versions and analyze refuses the
      # config init wrote ("Loaded a configuration file for version 4.37.7, but
      # running version 4.37.9"), so none of the single-action pull requests can
      # reach green on its own. They travel together.
      codeql-action:
        patterns:
          - "github/codeql-action*"
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 3
  # The `docker` ecosystem above reads the Dockerfile only. The bundled
  # database lives in `docker-compose.yml`, which GitHub treats as its own
  # ecosystem, so without this block a new PostgreSQL minor release never
  # reaches us and the pin ages silently.
  - package-ecosystem: "docker-compose"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 3
    ignore:
      # A PostgreSQL major is a migration, not an update: the on-disk format
      # changes, so the operator has to run pg_upgrade or dump and restore.
      # The first run of this ecosystem proposed 16.15 -> 18.6, which would
      # have handed self-hosters a database their data directory cannot be
      # read by. Minor releases still arrive as PRs; a major is a deliberate
      # project decision with a migration guide behind it.
      - dependency-name: "postgres"
        update-types: ["version-update:semver-major"]