ENG-5551 - Add grouped weekly Dependabot config for daisybill_api

[baueric]

Closes ENG-5551

Problem

This repo had no .github/dependabot.yml and automated-security-fixes was disabled outright (enabled=false, paused=false — off deliberately, not auto-paused). The "0 open Dependabot PRs" figure was misleading: nothing was running.

There are 9 open alerts on Gemfile.lock (2 high, 4 medium, 3 low):

Package	Severity	Patched in
addressable	high	2.9.0
concurrent-ruby	high (+2 low)	1.3.7
yard	medium ×2	0.9.42 / 0.9.44
rake	medium ×2	12.3.3
json	low	2.19.9

This is also the only public repo in the ENG-5537 set. Advisories here are visible to anyone, and anyone depending on the gem inherits them.

Change

Adds .github/dependabot.yml covering both ecosystems present in the repo:

• bundler (/) and github-actions (/, for .github/workflows/ruby.yml)
• schedule.interval: weekly, Monday 10:00
• open-pull-requests-limit: 5 per ecosystem
• Groups split production/development, each restricted to update-types: [minor, patch]

Format deliberately mirrors the config in daisyBill/daisybill (minus the private-registry and per-gem ignore blocks, which don't apply here).

Why update-types from the start

Per ENG-5558: the daisyBill config (PR #19078) omitted update-types and both grouped PRs it produced failed CI immediately. Restricting groups to minor/patch means breaking majors arrive as individual PRs that can be triaged on their own rather than blocking the whole group.

Lockfile review is required on every grouped PR here

update-types constrains only what Dependabot updates directly — transitive resolution is unconstrained. On daisyBill (ENG-5564) a transitive rack 2→3 forced a silent sinatra downgrade to 1.0 that broke Rails boot, and a jquery-ui minor bump lifted transitive jquery to 4.0.0 with CI fully green.

Neither rack nor jquery is present here, so those two specific guards don't apply. But this is a published gem — any resolution change in its lockfile is inherited by consumers, so read the Gemfile.lock diff on every grouped PR, not just the first.

Gem is alive — configure, don't disable

ENG-5551 asked whether the gem is still published and consumed, since disabling alerts (ENG-5539) would be more honest than configuring updates nobody merges.

It's live: daisybill_api v0.2.0 published 2026-03-24, 245 downloads on that version, 24,883 all-time, not yanked. Configuring updates is the right call.

Known limitation: stale gemspec constraints block some patches

Two alerts can't be fixed by a minor/patch group because the gemspec pins below the patched version:

• rake "~> 10.0" — needs >= 12.3.3 (major bump)
• bundler "~> 2.0" / others are fine; yard "~> 0.9.0" does reach 0.9.44

Dependabot will surface rake as an individual major-version PR. Widening that constraint is a separate call and out of scope for this PR.

Follow-up (not in this PR)

Dependabot security updates still need enabling on the repo — a settings change, not a file:

gh api -X PUT /repos/daisyBill/daisybill_api/automated-security-fixes

Deploy Note

Infrastructure — adds .github/dependabot.yml only. No gem code change, no version bump, no release.

Product Review

None

[baueric]

@maximsilver another one for dependabot grouped PRs

[Copilot]

Pull request overview

Adds a Dependabot configuration to enable scheduled, grouped dependency updates for this repository (Bundler + GitHub Actions), aligning with the goal of making dependency maintenance and alert remediation actionable.

Changes:

• Introduces .github/dependabot.yml with weekly (Monday 10:00) update checks.
• Configures grouped PRs for Bundler (split prod vs dev) and GitHub Actions, restricted to minor/patch updates.
• Caps open Dependabot PRs at 5 per ecosystem to avoid PR noise.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.