DoDiODev commented on PR #9089:
URL: https://github.com/apache/devlake/pull/9089#issuecomment-5508933883
## Open question for maintainers: automatic merging after a trial period?
This pull request deliberately does **not** enable any form of automatic
merging - every Dependabot pull request will need a human merge. Whether that
stays the case is a maintainer decision, and it is easier to make once there
is
some data, so this is only a question, not a proposal to change anything
here.
For context, since it is a common misconception: Dependabot itself cannot
merge.
The `automerged_updates` key disappeared with Dependabot Preview in 2021 and
`.github/dependabot.yml` has no auto-merge setting at all. What people call
"Dependabot auto-merge" today is three separate pieces, none of them in this
file:
1. the repository setting **Allow auto-merge**, which for an ASF repository
is
an INFRA/`.asf.yaml` matter;
2. **branch protection with required status checks** on `main` - without it,
auto-merge merges immediately and the CI signal is worthless;
3. a small workflow (~30 lines) that reads `dependabot/fetch-metadata` and
calls
`gh pr merge --auto --squash` only when `update-type` is
`version-update:semver-patch` (and optionally `…-minor`).
Two details make this cheap for this repository specifically: Dependabot pull
requests are branches in the repository rather than fork pull requests, so
they
do not sit in `action_required` and the checks run on their own; and a squash
merge takes the pull request title as the commit message, which already
carries
the `build(deps): …` prefix that `.github/workflows/commit-msg.yml` requires.
**The questions, concretely:**
1. Is automatic merging something you want at all, or do you prefer every
dependency change to pass a human review, regardless of severity?
2. If yes - how long should the trial period be in which everything is
merged by
hand? The schedule here is weekly, so an observation window of roughly
**6-8 weeks (about 6-8 update cycles)** would show how often a grouped
minor/patch pull request is green and mergeable unchanged, and how often
it
actually needs work. A longer window is of course fine; the point is to
decide on evidence rather than on a feeling.
3. What scope would you be comfortable with? A staged rollout would be the
careful version: start with **patch only, `github-actions` and `docker`**,
and extend to the `npm`/`pip` minor+patch groups only if the first stage
was
uneventful. Majors would never be in scope.
4. Can INFRA enable *Allow auto-merge* and the required status checks on
`main`?
Without both, the workflow is pointless, so this is worth clarifying
before
anyone writes it.
One optional addition that pairs well with this: Dependabot's `cooldown` key
can
delay a pull request until a release is a few days old, which takes the edge
off
the "compromised release published minutes ago" scenario that automatic
merging
otherwise amplifies. It is not used in this configuration and could be added
in
the same follow-up.
If the answer to (1) is yes, we are happy to prepare that follow-up pull
request
(the workflow file plus, if wanted, the `cooldown` entries) once the trial
period
has run. Nothing in the present pull request depends on the answer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
