Hi all! I’m using this officially documented GitHub Actions workflow to auto-merge Dependabot PRs. It works, but if I want the auto-merge to wait until CI checks pass, I have to turn on the “Include administrators” branch protection setting, which I’d rather leave off. Specifically, I want to be able to push to main myself directly, without a PR, but I want PRs to block on CI passing before they can be merged.
Any ideas? Can I run the auto-merge with a token that doesn’t include the administrator permissions somehow? Or anything else? Thanks in advance!
(Lots of related background in Dependabot auto merge not working · Issue #1973 · dependabot/dependabot-core · GitHub btw, but no solution for this specific problem.)
jsoref
March 30, 2022, 3:05am
#2
I’ve left some suggestions here:
opened 12:32PM - 02 Jun 20 UTC
F: preview-migration
<!-- The Dependabot team is currently at reduced capacity, because of this our
… response times on issues will be slower than we'd like. -->
<!-- If it's PRIVATE repository, please fill out GitHub's support form:
https://support.github.com/contact?form%5Bsubject%5D=Re%3A+Dependabot+Preview
Be sure to include the repository name and any troubleshooting steps you've tried so far. -->
For my private repository it's not possible to add the auto merge feature. I added dependabot via the web interface and I receive PRs but the PRs are not merged automatically.
After this did not work I also tried via the dependabot config. The behaviour is the same. The check runs daily and creates PRs but does not merge them.
```yaml
version: 1
update_configs:
- package_manager: "javascript"
directory: "/"
update_schedule: "daily"
automerged_updates:
- match:
dependency_type: "development"
# Supported dependency types:
# - "development"
# - "production"
# - "all"
update_type: "all"
# Supported updates to automerge:
# - "security:patch"
# SemVer patch update that fixes a known security vulnerability
# - "semver:patch"
# SemVer patch update, e.g. > 1.x && 1.0.1 to 1.0.3
# - "semver:minor"
# SemVer minor update, e.g. > 1.x && 2.1.4 to 2.3.1
# - "in_range"
# matching the version requirement in your package manifest
# - "all"
- match:
dependency_type: "production"
update_type: "all"
```
If you could confirm that one or the other work, I think we could probably file a bug (or two or three) against the documentation.