ci: add Dependabot for weekly cargo updates and remove nightly CI run

[crprashant]

What

Closes #22.

• Add .github/dependabot.yml — native Dependabot config that opens a single grouped cargo update PR weekly (Monday 03:00 UTC), labeled dependencies.
• Remove the nightly schedule: trigger from .github/workflows/ci.yml — CI now runs on PRs, pushes to main, and manual dispatch only.

Why Dependabot instead of a custom workflow

The first revision of this PR used a custom workflow with peter-evans/create-pull-request. As @pinodeca pointed out in review, that approach depends on the "Allow GitHub Actions to create and approve pull requests" repo/org setting, which can't be enabled here due to org policy.

Dependabot raises PRs through a separate permission system that is not governed by that setting, so it works regardless. This is "Option 1" from the review discussion. The custom deps-update.yml workflow has been removed entirely.

Key config choices

• versioning-strategy: lockfile-only — updates only Cargo.lock, never the requirements in Cargo.toml. This preserves the exact = pins on pgrx, duroxide, and duroxide-pg (and the duroxide/duroxide-pg compatible-pair invariant) while still pulling in patched transitive and range-versioned dependencies. Equivalent to cargo update.
• groups: { cargo: { patterns: ["*"] } } — collapses everything into one weekly PR instead of one-per-crate.
• commit-message: { prefix: chore, include: scope } — produces chore(deps): ... commit titles, matching the repo's conventional-commit style.
• The generated PR is validated by the existing CI (clippy, unit, E2E, upgrade tests).

Notes

• The independent nightly build in docker.yml is intentionally left untouched.
• No CHANGELOG.md entry — this is CI tooling, not a user-facing/release change.

[pinodeca]

I'm unable to modify to check the box “Allow GitHub Actions to create and approve pull requests”. Similarly, I can't check "Read and write permissions". I thought the latter might be a prerequisite for the former.

I don't know if this is due to a Microsoft GH org-wide policy, but that would be my guess.

Opus 4.8 suggested some alternative approaches:

• Use Dependabot
• Use a custom token
• Don't open a PR, just have the workflow post a new lockfile as an artifact

I prefer the first, and it seems I'm able to to check the box that allows Dependabot to open PRs... although that opens an editor to create a commit to add .github/dependabot.yml.

Opus 4.8 wrote:

No dependabot.yml exists yet. Here's the key insight: that checkbox only restricts the default GITHUB_TOKEN. There are three escape hatches, ranked by how well they fit your situation.

Option 1 — Dependabot (recommended, fully native)

Dependabot opens PRs through a separate permission system that is not governed by the "Allow GitHub Actions to create and approve pull requests" setting. Microsoft orgs almost always allow it. It also produces a cleaner per-update PR with a changelog, and it triggers CI normally.

The catch for this repo: you pin duroxide, duroxide-pg, and pgrx with =, and you want lockfile-only updates (don't let it bump Cargo.toml requirements). Cargo's versioning-strategy: lockfile-only does exactly that — it only updates Cargo.lock, preserving your exact pins and the duroxide/duroxide-pg compatible-pair invariant.

I can drop in .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: cargo
    directory: "/"
    schedule:
      interval: weekly
      day: monday
      time: "03:00"
    versioning-strategy: lockfile-only   # only touch Cargo.lock, never Cargo.toml pins
    open-pull-requests-limit: 5
    labels:
      - dependencies
    groups:
      cargo-deps:
        patterns: ["*"]                  # one grouped PR, mirrors `cargo update`

The groups block makes it open a single weekly PR (like the cargo update approach) instead of one-per-dependency. This would replace deps-update.yml entirely — no PAT, no org-setting change needed.

Option 2 — Keep the workflow, use a token that isn't GITHUB_TOKEN

[PINO OMITTED FOR BREVITY]

Option 3 — Partial automation, no PR creation at all

[PINO OMITTED FOR BREVITY]

---

My recommendation: go with Dependabot (Option 1) — it's the cleanest fit, removes the custom workflow and the PAT entirely, and sidesteps the org policy by design. Want me to add the dependabot.yml above and update the PR (removing deps-update.yml and keeping the ci.yml schedule removal)? Or if you'd rather keep your workflow, I can wire up Option 2 or convert it to the branch-push approach in Option 3.

[crprashant]

@pinodeca thanks for the review — good call on the org policy blocker.

I've switched to Option 1 (native Dependabot) and removed the custom deps-update.yml workflow entirely. Dependabot opens PRs through its own permission system, so it sidesteps the "Allow GitHub Actions to create and approve pull requests" setting.

The new .github/dependabot.yml:

• Runs weekly (Monday 03:00 UTC), one grouped PR for all cargo updates, labeled dependencies.
• Uses versioning-strategy: lockfile-only so it only touches Cargo.lock and leaves the = pins on pgrx / duroxide / duroxide-pg intact (keeping the duroxide ↔ duroxide-pg compatible pair) — effectively cargo update.
• Uses commit-message.prefix: chore + include: scope to match the repo's conventional-commit style.

Tested live on my fork (crprashant/pg_durable): I enabled Dependabot there and let it run against this exact config. Results:

• It opened a single grouped PR titled chore(deps): bump the cargo group with 5 updates — confirming the grouping and the chore(deps): conventional-commit prefix.
• The diff touched only Cargo.lock — Cargo.toml was unchanged and the = pins on pgrx / duroxide / duroxide-pg were preserved, so lockfile-only behaves exactly like cargo update and the duroxide ↔ duroxide-pg pair stays locked together.
• Updates picked up were transitive/range-only (e.g. chrono 0.4.44 → 0.4.45, a reqwest dedup, plus a few others). I've since reverted the fork to its original state.

The ci.yml nightly schedule removal is unchanged. PR description updated to match. PTAL 🙏

[pinodeca]

Reviewed with Opus 4.7:

Minor suggestions (non-blocking)

1. open-pull-requests-limit: 5 is effectively a no-op because everything is grouped into one PR. Either lower it to 1 for clarity, or just delete the line (default is 5 anyway). Not a functional issue — purely cosmetic.
2. Consider follow-up ecosystems. The repo uses many GitHub Actions (actions/checkout@v4, actions/setup-python@v5, peter-evans/create-pull-request@v6 in examples, etc.) and Docker images (Dockerfile, Dockerfile.release). Adding package-ecosystem: github-actions and package-ecosystem: docker blocks would catch supply-chain updates there too. Reasonable to defer to a follow-up — issue #22 only scoped cargo.
3. No reviewer auto-assignment. Without reviewers: / assignees:, the weekly PR can sit unnoticed. Worth adding once you know who owns dep upgrades, but a separate concern.
4. Auto-merge / branch-protection interaction is out of scope here, but worth deciding before the first PR lands — otherwise someone has to manually merge a green Dependabot PR every Monday.