馃 [rubykatzen/baseline]:
Goal
Consider adding an optional reusable Baseline workflow that enables auto-merge for selected Dependabot pull requests across consumer repositories. This is repository hygiene that can provide a more homogeneous and centrally managed dependency update process across organizations and language stacks.
Initial policy
Patch dependency updates are the likely default candidate for auto-merge. Development-tool and other development dependency updates may also be safe to merge relatively freely when the repository has meaningful CI coverage.
This fits the Release Please lifecycle: dependency updates accumulate on main, the release pull request exposes the complete release contents for review, and the full test suite runs again before the release is merged. A dependency bump therefore remains visible and validated before publication even when its original pull request was merged automatically.
Minor updates may be appropriate for selected dependency classes or repositories, but should require an explicit policy decision. Major updates should remain manual by default.
Safety boundary
Do not enable auto-merge merely because a pull request was opened by Dependabot. The repository must have enforced merge requirements so gh pr merge --auto --squash waits for meaningful CI instead of merging immediately.
Before implementing this workflow, determine how Baseline will guarantee or verify:
- required test, lint, and build checks through branch protection or repository rulesets;
- compatibility with the Baseline squash-only merge policy;
- reliable identification of Dependabot pull requests and update types through
dependabot/fetch-metadata;
- treatment of production versus development dependencies;
- treatment of security updates and grouped updates;
- whether dependency review should be a required check where GitHub supports it;
- an explicit consumer override for the maximum auto-merged update type.
Candidate interface
Export an optional reusable workflow such as dependabot-automerge-shared.yml. The conservative default would allow patch updates only. Consumers could explicitly expand the policy where their test coverage and dependency risk permit it.
The workflow should use the repository GITHUB_TOKEN, grant only the required permissions, verify the Dependabot actor, inspect update metadata, and enable squash auto-merge rather than merging before required checks pass.
Open questions
- Should development dependencies permit minor updates by default?
- Should security updates follow the semantic-version policy or have a separate policy?
- Should the workflow refuse to run unless required checks can be confirmed?
- Does branch protection/ruleset enforcement need to be implemented in Baseline before this capability ships?
- How should grouped updates with mixed dependency types or update levels be classified?
References
Done when
The applicability boundaries are decided and Baseline either exports a tested, conservative auto-merge workflow guarded by enforced CI requirements or documents why this capability should remain repository-specific.
馃馃攼鈿栵笍
馃 [rubykatzen/baseline]:
Goal
Consider adding an optional reusable Baseline workflow that enables auto-merge for selected Dependabot pull requests across consumer repositories. This is repository hygiene that can provide a more homogeneous and centrally managed dependency update process across organizations and language stacks.
Initial policy
Patch dependency updates are the likely default candidate for auto-merge. Development-tool and other development dependency updates may also be safe to merge relatively freely when the repository has meaningful CI coverage.
This fits the Release Please lifecycle: dependency updates accumulate on
main, the release pull request exposes the complete release contents for review, and the full test suite runs again before the release is merged. A dependency bump therefore remains visible and validated before publication even when its original pull request was merged automatically.Minor updates may be appropriate for selected dependency classes or repositories, but should require an explicit policy decision. Major updates should remain manual by default.
Safety boundary
Do not enable auto-merge merely because a pull request was opened by Dependabot. The repository must have enforced merge requirements so
gh pr merge --auto --squashwaits for meaningful CI instead of merging immediately.Before implementing this workflow, determine how Baseline will guarantee or verify:
dependabot/fetch-metadata;Candidate interface
Export an optional reusable workflow such as
dependabot-automerge-shared.yml. The conservative default would allow patch updates only. Consumers could explicitly expand the policy where their test coverage and dependency risk permit it.The workflow should use the repository
GITHUB_TOKEN, grant only the required permissions, verify the Dependabot actor, inspect update metadata, and enable squash auto-merge rather than merging before required checks pass.Open questions
References
Done when
The applicability boundaries are decided and Baseline either exports a tested, conservative auto-merge workflow guarded by enforced CI requirements or documents why this capability should remain repository-specific.
馃馃攼鈿栵笍