Context
We currently auto-merge all minor/patch updates (with a 14-day waiting period and CI gates). Major updates remain manual because they can introduce breaking changes.
However, for certain well-known packages with strong semver discipline and low breaking-change risk, we could safely auto-merge majors too.
Candidate packages for major auto-merge
| Package |
Rationale |
| `actions/*` |
GitHub's official actions — majors are well-communicated, rarely break |
| `docker/*` |
Docker's official actions |
| `github/*` |
GitHub's other actions |
| `lscr.io/linuxserver/*` |
LinuxServer images — versioned conservatively |
| `docker.io/library/*` |
Official Docker Hub images (postgres, redis, etc.) |
Safeguards that would remain
- 14-day `minimumReleaseAge`
- CI must pass (required status checks)
- `automerge` label for visibility
- Schedule limited to weekends + Fridays
Decision criteria
Before enabling, validate:
- The package org has a strong track record of semver compliance
- Our CI catches breakage reliably for that ecosystem
- Rollback is straightforward if something breaks
Context
We currently auto-merge all minor/patch updates (with a 14-day waiting period and CI gates). Major updates remain manual because they can introduce breaking changes.
However, for certain well-known packages with strong semver discipline and low breaking-change risk, we could safely auto-merge majors too.
Candidate packages for major auto-merge
Safeguards that would remain
Decision criteria
Before enabling, validate: