Support auto merge in Dependabot
DominicBoettger opened this issue · 104 comments
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.
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"Same here. Is anything wrong with my project configuration? https://github.com/leonardovillela/redux-zero-chat/blob/master/.dependabot/config.yml
I already have enabled auto-merge in my account. As you can see the PR's are open but not auto-merged 🤔
Thanks for the feedback and sorry for the confusion here.
Auto-merge will not be supported in GitHub-native Dependabot for the foreseeable future. We know some of you have built great workflows that rely on auto-merge, but right now, we’re concerned about auto-merge being used to quickly propagate a malicious package across the ecosystem. We recommend always verifying your dependencies before merging them.
Okay, but I'm not using GitHub-native Dependabot, so auto merging is supposed to work, right?
@leonardovillela it looks like you don't have CI set up on the repo, which is why Dependabot doesn't want to automerge: leonardovillela/redux-zero-chat#2
You need to add some CI check on pull requests, you could add a GitHub action that runs on every push. Doesn't actually have to do anything as long as the task succeeds.
If you don't mind adding another GitHub Bot to the mix, I built an open source bot called Kodiak which supports auto merging pull requests.
There's specific instructions for using Kodiak with Dependabot here: https://kodiakhq.com/docs/recipes#automated-dependency-updates-with-dependabot
Also, there are a ton of other GitHub Bots doing similar things. Here's a non-exhaustive list: https://kodiakhq.com/docs/prior-art-and-alternatives
@infin8x I understnd the security concerns and wanting to make this something we have to do intentionally, but I haven't found a bot that can distinguish the pacakge name and semver bump before merging. If this isn't going to be supported in dependabot directly is there a way to add labels based on names and semver?
An example of our current config:
automerged_updates:
- match:
dependency_name: "eslint"
- match:
update_type: "semver:minor"
dependency_name: "@fortawesome/free-brands-svg-icons"
We don't want to automerge everything (or even most things) so automerging based on a label applied to every update doesn't work, we'd need to be able to label based on the same criteria we used to auto merge with.
@infin8x I understand the security concern but we were hoping to set our target_branch to something that is not our default branch and then auto-merge into that branhc to limit the number of PRs that get opened per project. Many integration services like Chromatic, Heroku, etc. have costs associated with each PR that gets created in a repo so this is an important capability for us. I think you need to reconsider this policy to at least allow auto-merge on non-default branches.
@chdsbd Can Kodiak distinguish between patch, minor, and major versions?
@danielbachhuber Sadly not.
There was a discussion about adding that kind of metadata in a structured form via probot metadata, but I don't think that's gone anywhere yet.
#2294 would also make automatic updates based on type easy.
A potentially less robust solution would be to parse the update type from the PR description.
Assuming the following example is consistent I think a github action could label the PR based on the PR description.
Bumps eslint from 7.6.0 to 7.7.0.
...more content...
Here's a example script that could probably be integrated into some GitHub Action or bot:
https://runkit.com/chdsbd/5f3c822e5eda78001ac183df
const semver = require('semver')
const PR_DESCRIPTION = `\
Bumps eslint from 7.6.0 to 7.7.0.
Release notes
Sourced from ...`
const regex = /^Bumps\s.*\sfrom\s(.*)\sto\s(.*)\./;
/* determine the update type (major, premajor, minor, preminor, patch, prepatch, or prerelease) from a dependabot PR */
function parseUpdateType(x) {
const match = x.match(regex)
const prevVersion = match[1]
const newVersion = match[2]
return semver.diff(prevVersion, newVersion)
}
parseUpdateType(PR_DESCRIPTION)
/* equals "minor" */In our org we have automerge setup for when branch conditions are met.
And we always require review, we like just being able to approve a PR and then it automatically merges.
It saves a few clicks in the UI and also means that if CI is retriggered it will merge after CI is green.
Saves have to type @dependabot merge which isn't too bad but would be nice to get automerge back
In our org we have automerge setup for when branch conditions are met.
And we always require review, we like just being able to approve a PR and then it automatically merges.It saves a few clicks in the UI and also means that if CI is retriggered it will merge after CI is green.
Saves have to type
@dependabot mergewhich isn't too bad but would be nice to get automerge back
That makes me wonder if you could setup a GHA to auto comment @dependabot merge when a PR is approved in review. Doesn't solve people wanting unattended auto-merge, but might solve your use case.
I can do that but just means adding another github action all over the place, previously we were able to control this in org settings in dependabot which was nice.
There is no automerging support in GitHub-native Dependabot [...] Several 3rd-party GitHub Actions and bots can replicate the automerge feature.
I must say this is the least helpfull feature migration help I have ever encountered. What about putting a link to somewhere where you can read about what to do?
Preferably a one-click-to deply action that just works.
Edit: Use this instead: https://github.com/SimpleJWT/drf-SimpleJWT-React/blob/7fe37747f9b4385faeaf5ec57b650ff21d82c1ae/.github/workflows/automerge.yml#L1
It takes advantage of wait for status check GitHub action and automerge GitHub action (which can delete branch).
Old Response:
For anyone looking for auto-merge, I believe there is a marketplace GitHub action that can do it for you, but I've also created a GitHub action file here: cookiecutter/cookiecutter-django#2868 but credit goes to the Medium blog post that I took the code from. I can't seem to find the blog post anymore, but I hope that file helps anyone who want further configuration! (EDIT: Found it! https://medium.com/@toufik.airane/automerge-github-dependabot-alerts-with-github-actions-7cd6f5763750):
Quickly, here're the file contents:
name: "Dependabot Automerge - Action"
on:
pull_request:
jobs:
worker:
runs-on: ubuntu-latest
if: github.actor == 'dependabot[bot]'
steps:
- name: automerge
uses: actions/github-script@0.2.0
with:
script: |
github.pullRequests.createReview({
owner: context.payload.repository.owner.login,
repo: context.payload.repository.name,
pull_number: context.payload.pull_request.number,
event: 'APPROVE'
})
github.pullRequests.merge({
owner: context.payload.repository.owner.login,
repo: context.payload.repository.name,
pull_number: context.payload.pull_request.number
})
github-token: ${{github.token}}
Does anyone know if this will auto-merge whatever PR from a user who changed their username to dependabot[bot]?
While I understand the refusal to implement this feature in Dependabot due to the security hole it opens up, the functionality provided by Dependabot's automerged_updates feature is very hard to replicate with the tools currently available.
The most important void in the current infrastructure is the lack of metadata (the version numbers being the most essential bits of information) in the pull requests submitted by Dependabot, or by any other bot, for that matter. This is needed to replicate the behaviour of update_type: "semver:minor" and similar in the non-GitHub-native Dependabot.
While Probot could work as a way to provide this metadata – it is, as it even describes itself: A hack. To enable the community to build alternatives to the automerged_updates feature, GitHub needs to provide us with a non-hacky implementation of pull request metadata that can be used in GitHub actions so at least the version numbers are available for comparison.
The more metadata available, the better, of course. As an example, to address @mathiasrw's issue, a signature could be added to the metadata, so the origin of the PR could be verified before merging.
I completely understand the security concerns, but I believe there's a gray area here between auto-merging unknown PR's and not having this feature at all.
Maybe we can have a treat approval as request to merge, or auto-merge for specific semver like minor, or maybe have auto-merging to a non-default branch that will be fully reviewed ie. auto-merge in develop that will be reviewed before merge to master.
FWIW, I tried the github action approach @Andrew-Chen-Wang mentioned above but it only works if there are no other pending github status checks. If you have another required status check that takes a while to finish (i.e. Travis CI), the action doesn't wait for it and fails with the following error:
Error: Required status check "Travis CI - Pull Request" is queued.The action didn't wait for Travis CI - Pull Request status check to finish
@mkay581 I've redeveloped it in SimpleJWT's repositories to use two actions: wait for status check and automerge and delete branch. https://github.com/SimpleJWT/drf-SimpleJWT-React/blob/7fe37747f9b4385faeaf5ec57b650ff21d82c1ae/.github/workflows/automerge.yml#L1
I want to mention as a fair warning that dependencies do break once in awhile, and you should always keep an eye out for even minor changes sometimes. I had a conversation with browniebroke in the cookiecutter-django library, and decided not to implement this automerge functionality there due to many packages having deprecated warnings, breaking changes, etc., agreeing to needing to manually review each one. And cookiecutter-django has a LOT of dependencies. So that's just something to think about.
We got the alternative here: https://twitter.com/github/status/1336360682221133827?s=20
Check out auto-merge! Now, when your branch protection rules are met, your changes approved, and your checks are green, GitHub can automatically merge your pull request for you.
@peaceiris It seems like someone still has to hit the button each time?
We do not know the details yet. It will start rolling out next week. I hope we can set the auto-merge for a whole repository/account without approval.
It seems like this (auto-merge) is applied individually to each pull request. The scenario is you are waiting for checks to pass or approvals to be applied via review, but you want the PR to merge once those conditions are met.
It does not seem you can globally apply this to an entire repository (and arguably probably don't want to).
It does not seem you can globally apply this to pull requests from repo admins, code owners, or specific users or groups that have been given permissions to a repository (this might be more reasonable than globally applying to an entire repository). I would imagine this option (if it were made available) would allow us to globally grant dependabot permissions to auto-merge within a repo, but not anything else (ex: admins, code owners, or other users/groups with permissions might not need/want auto-merge globally and would prefer it on an individual PR basis, which is how it currently seems to work).
If you have checks that need to pass before you want to merge the dependabot update PRs, you can use a combination of the "automerge" and "wait for status" actions.
What would it take for this decision to be reconsidered?
The way I see, the security protection here is: updates will roll out slowly, so if it's malicious, it won't affect too many projects. Looks like this is only really slowing the whole process. I understand that as a temporary solution, but I'd expect something else to happen in the short term future.
I also don't expect a manual review to catch a security issue, unless it is a very known issue and you're specifically looking for it. I can't keep them all in my head and I don't want to go over every dependency update. We get hundreds of those per day. I expect that people will configure auto merge anyway (with fewer features, because now we can't enable it only for minor versions), or simply do them manually, but blindly.
It would be interesting if it could auto merge if all github workflow checks pass, and there were a specific workflow available to check if any packages have known vulnerabilities and prevent merging if true. With that, auto merge could work for those who's packages are up to date with no known vulnerabilities, and if any vulnerability is present (even if it's not in the package being updated) all merges would have to be manual until the vulnerability is resolved.
I know that's not perfect, but it might be reasonable enough.
I made this article to help explain how to auto merge
https://jayisscott.medium.com/dependabot-auto-merging-prs-7b20459ed8e9
cc @asciimike would love to get your thoughts on this. It's clearly something that a lot of people really valued from the old dependabot, and not all projects/workflows are affected by the risk equally (not everyone autodeploys the main branch and may do a dependency check before manually kicking off a release, libraries still require a manual release etc), but at the same time the potential risk for massively rolling out a malicious update are scary.
I've been testing @Mergifyio for a few weeks and just wanted to mention that they provide a great alternative to Dependabot's auto-merge functionality. Works for protected branches, required code reviews, required checks, CODEOWNERS and restricted push. This configuration handles it all:
pull_request_rules:
- name: Automatic approve on dependabot PR
conditions:
- author~=^dependabot(|-preview)\[bot\]$
actions:
review:
type: APPROVE
- name: Automatic merge on approval
conditions:
- author~=^dependabot(|-preview)\[bot\]$
actions:
merge:
method: merge
strict: smartAuto-merge will not be supported in GitHub-native Dependabot for the foreseeable future. We know some of you have built great workflows that rely on auto-merge, but right now, we’re concerned about auto-merge being used to quickly propagate a malicious package across the ecosystem. We recommend always verifying your dependencies before merging them.
Would it be possible to add support for auto-merge if the dependency is an internal organization package?
@infin8x
If you don't mind using another GitHub App for helping with auto merge, I made an open source GitHub App, Kodiak, that supports auto merging Dependabot PRs based on upgrade type (major, minor, patch).
It has a pretty simple config.
#.kodiak.toml
version = 1
# auto merge minor and patch updates made by Dependabot
[merge.automerge_dependencies]
versions = ["minor", "patch"]
usernames = ["dependabot"]
# let Dependabot update its own PRs
[update]
ignored_usernames = ["dependabot"]Re: @sehenst
Would it be possible to add support for auto-merge if the dependency is an internal organization package?
This is one of the few situations that we think it's less-insecure to use auto-merge. I do think it's a little tough to know what "internal" packages are (e.g. is any private registry/repo considered internal? What if it's just mirroring a public registry?), so I doubt that we'll build it directly in, but instead recommend folks use an Action or a standalone app configured according to their security/risk profile. I'm working on some docs to help folks with this.
Side note, _infin8x is no longer working on Dependabot, so he's probably not going to be responding.
I think one completely overlooked use case is that dependabot can keep dependencies of hobby and community projects updated. While serious projects, where the security impact is large, have the manpower and dedication to approve and review the updates, these small projects, where the security impact is none or low, do not. Also, many of my projects are static websites, where security issues in dev tools required to build the site have zero actual impact (like various DDoS security vulnerabilities, etc.). Today, I woke up to this:
Except one, I'm not paid to maintain any of the projects. I want to keep them safe and updated, and I occasionally find some free time to make them better, or once, twice a year, we have a community sprint where we work on them. I can't imagine thoroughly reviewing the dependencies, it's just impossible. Even if the bot sends the PRs my way without automerging, it won't make me to review them. I'll just mindlessly click the PR to upgrade. It'll only add drag to maintaining them and drain my time and resources. The issues any vulnerability could cause on these projects are so small it just isn't worth the hassle of preventing them to happen, this is a hotfix scenario in case something happens (happened only once for the past 10 years). Letting the dependencies rot and upgrading them all once a year would be much worse.
We're advised to use bots and GitHub Actions, but for hobby and community projects, that's added complexity, which only requires installing on each repo, configuring on each repo, maintaining, explaining, documenting - so again, that's draining volunteering time and resources. Not mentioning not all the projects use GitHub Actions, so I'd have to find workarounds e.g. for CircleCI.
Previously, we could choose whether to turn automerging on or off, depending on how serious the project is. We could assess the risks ourselves. Now GitHub removes the option and decides for us, like a parent.
Unlike others in this discussion, I do not entirely understand the security reasons for not implementing the feature. I think that requiring people to go to the PR and manually approve the upgrades won't add security, it'll only add annoyance. People won't be reviewing, they'll see green checks and will just merge the PR and see if something broke 🤷 I think this might cause the opposite, in fact. I think this can cause many volunteer maintainers to feel like there is an endlessly growing stack of dependency upgrade PRs to go through, which will drain their energy and time, which will make them feel like maintaining the project is not a joy, but a job. So they'll either let the PRs rot, or they'll disable dependabot, or they'll never turn it on in the first place. Which will cause the projects' dependenices to rot, and outdated dependencies are exactly where vulnerabilities thrive.
Workaround... 😄
Please note that we only use this for internal dependencies (i.e., our own private packages).
name: Java CI with Gradle
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
distribution: 'adopt'
java-version: '11'
- name: Build with Gradle
run: ./gradlew build
env:
GRADLE_BUILD_USERNAME: ${{ secrets.**********************}}
GRADLE_BUILD_TOKEN: ${{ secrets.********************** }}
- name: "Auto-merge ********************** dependency updates"
if: ${{ success() && github.actor == 'dependabot[bot]' && startsWith(github.event.pull_request.title, 'Bump ********************** from') }}
uses: actions/github-script@v3
with:
github-token: ${{secrets.********************** }}
script: |
github.issues.createComment({
owner: context.payload.repository.owner.login,
repo: context.payload.repository.name,
issue_number: context.payload.pull_request.number,
body: '@dependabot squash and merge'
})
- name: Add reviewers on failed ********************** bumps
if: ${{ failure() && github.actor == 'dependabot[bot]' && startsWith(github.event.pull_request.title, 'Bump ********************** from') }}
uses: actions/github-script@v3
with:
github-token: ${{secrets.**********************}}
script: |
github.pulls.requestReviewers({
owner: context.payload.repository.owner.login,
repo: context.payload.repository.name,
pull_number: context.payload.pull_request.number,
team_reviewers: [ '@**********************' ]
})
I've helped maintain a number of both popular and not-so-popular OSS projects, and while I understand the convenience, I also think Github is making a wise choice here.
Supply chain attacks are already happening and they are only going to increase in the future.
If you really want auto-merge, either setup a GitHub action, or spin up your own copy of dependabot, or switch to renovate, or simply lower the frequency so that you can handle updates as a weekly task.
IMO handling updates with a few manual clicks on PR's is trivial and takes less than 30 seconds for me most of the time.
This change actually makes my application less secure. In the past we could rely on detection of new maintainers from dependabot to prevent auto-merging suspicious packages. That is the only supply chain attack that manual review prevents and it is easy to automate and hard for humans to do.
It isn't possible to audit every commit in every package we depend on, we rely on those package maintainers to do that work. The supply chain threat that seems to be the focus of this change is that an unknown malicious actor could push a new version of a package and have it propagate to everyone. Forcing us to rely on a third party action to auto merge removes this protection and adds significantly more work to the process of staying up to date.
What is more likely to happen after this change is that deeply nested OSS packages who are now forced to manually merge updates will simply ignore those updates or be overwhelmed by the flood or work and abandon their packages. That is an actual critical threat to our supply chain. As transitive dependencies fall further behind and fail to patch known vulnerabilities those vulnerabilities will be easy to exploit with automated tools and detection. The theoretical risk of a malicious packages propagating to the ecosystem that is somehow prevented by application owners clicking a green button is nowhere near as important or as critical as using these components with known vulnerabilities will be.
It's too bad because dependabot was a fantastic service that did everything we needed. Sad to see this product damaged by a miss understanding of the threats that face application owners and our users.
How does 30s long manual merging of the PRs, which doesn't include any deeper consideration or investigation of the updates, prevent supply chain attacks? The only real difference is that it's me spending time on enabling them instead of a bot doing it for me.
I wouldn't advocate for auto merging being anything near to default behavior, it should be opt-in with warnings and "I know what I'm doing" checks.
@honzajavorek
I had the same problem as you had.
I just drop dependabot and started use renovatebot.
just install this: https://github.com/marketplace/renovate
and drop a file similar to this one:
renovate.json
{
"extends": [
"config:base"
],
"schedule": ["after 7pm and before 7am"],
"prConcurrentLimit": 2,
"packageRules": [
{
"matchUpdateTypes": ["minor", "patch", "pin", "digest"],
"automerge": true
},
{
"matchDepTypes": ["devDependencies"],
"automerge": true
}
]
}I hope you can evaluate if that tool is better for your use case.
Dependabot's goal is to keep apps secure by keeping their dependencies up to date, not to simply keep dependencies always updated. We've found a correlation between up-to-date dependencies and more secure apps, but it's important to remember that correlation isn't causation! Keeping dependencies up to date is more likely to result in fixing latent bugs that might otherwise turn into vulnerabilities; however, it comes with an increased risk that a new release contains or enables malicious behavior. Security updates, while likely more safe, are still potentially vulnerable to this (imagine an attacker purposefully introducing a benign security vulnerability that's designed to get caught, followed by a patch that automerges an actual vulnerability). Is automerge a real risk in these cases? Recent history suggests it is.
When I worked at Google, we used to joke that "one in a million chances occur dozens of times every second" (true story), and with the scale we're operating at (Dependabot is the single largest creator of PRs at GitHub), it's possible that even small vulnerabilities will affect a lot of users and cause a lot of harm. The difference here is not a "misunderstanding of threats faced" it's that we're considering risks differently.
It should not be surprising that individuals working on projects they know well have a higher appetite for risk than a product with millions of users ranging from students working on homework projects to organizations larger than GitHub. We have to build a product that keeps everyone secure, and sometimes that means making choices that aren't locally optimal for one set of customers, but are globally optimal across the customer base.
The team and I recognize that it is effort to keep dependencies up to date, especially for OSS maintainers (we built Dependabot, after all). For those of you who have vetted your supply chain or are willing to accept the risks, the "opt-in" solutions exist. There are a plethora of apps (e.g. kodiak), Actions (e.g. merge-me), other products (e.g. renovate), a cron job that just runs npm update every day, etc. that can be used instead if automerge is the number one feature. We think that a user's decision to use a tool like this is a stronger signal of their willingness to accept risk than automerge: true.
I recognize that for some of you, nothing short of automerge: true will make you happy. As of right now, we can't offer that, and if that means you cease to use Dependabot, I'm sorry. Hopefully future changes to reduce noise, more precisely target vulnerable dependencies, or validate the integrity of packages will change the balance of power in supply chain attacks, and we can get to the point where folks can keep the right dependencies up to date with minimal burden. Until then, we'll do the best we can to work towards that goal, and welcome your feedback on how we can collectively make software more secure along the way.
@asciimike you're relying on a catch phrase "correlation isn't causation" to shrug off the very real fact that updated dependencies are a significant indicator of project quality and security. Your specified threat of novel supply chain attacks, while interesting to dream about, are less of a risk for the majority of Github projects than the well researched OWASP Using Components with Known Vulnerabilities where the most applications are actually vulnerable. There are millions of examples of out of date dependencies causing real world breach for every one of your example targeted attacks. The real world isn't what you imagine it to be and our applications are substantially more likely to be compromised by an out of date dependency than a malicious commit and even if that were not the case clicking a green button when tests pass doesn't do anything to prevent the later.
You're also mixing up the automated security bump GitHub system built on dependabot with the opt in configuration driven tool that dependabot was built as. Projects which include a dependabot configuration file have to be close to 0% of the total projects on Github. Treating them as vulnerable to the same threats as a hobby project doesn't make any sense. Enabling dependabot and writing tests to ensure that only quality updates are merged is a hallmark of professionalism, please don't take away tools that help us to do our job well.
Lastly while blanket automerging may represent an issue the original dependabot allowed for significant narrowing of the scope for each PR which allows automerging to work securely. Security conscious maintainers of applications could restrict auto merging to specific packages with more trusted security practices and the auto merge automatically stopped when a new maintainer was detected. The solutions bandied about here and in other issues do not have access to the same depth of metadata on each update that dependabot does and so cannot be made as secure as the original feature.
I know you're seeing these complaints as coming from maintainers with no clue and don't know what we're talking about. I don't know if you meant the google remark to be condescending or it just came off that way to me. Please understand that this (and many other threads on this subject) are full of professional developers who are disagreeing with you for very good reasons and have been doing so for months. This change will make our applications less secure and distract from the work of building great things in order to take a few moments every morning to blindly click a green button instead of allowing well informed automation to do it for us. That's not a good tradeoff.
My comments are never intended as condescending, and I apologize if they came off as so. It was intended to just be a statement of us having different lenses through which we view the problem, as that's the heart of the disagreement. I respect everything folks have to say, and the arguments for why this feature makes sense in your use cases make sense. My concern isn't how folks on this thread use automerge, it's how everyone who isn't participating in this thread would use it.
Existing solutions aren't perfect, e.g. Kodiak can do semver based merges, but not dependency_type, and I'm happy to see if we can add that info (likely as labels or a metadata comment on the PR) for folks to act on if that would help. For folks with good enough test coverage and CI, merging based off this info should be easy enough (e.g. https://github.com/pascalgn/automerge-action 's MERGE_LABELS) that it's a reasonable "opt-in" to prevent folks who don't from YOLO merging everything.
I'm probably one of these potential users that "would use automerge but are not participating in this thread". I don't have any background in IT, and only maintaining a few smaller projects in my freetime. If I get a dependabot PR and the checks are green, I often just click merge without even looking at the changed files. Sometimes, if time permits, I skim over the changelog. Today was the first time I read about "chain of supply attacks".
That being said,
For those of you who have vetted your supply chain or are willing to accept the risks, the "opt-in" solutions exist. There are a plethora of apps (e.g. kodiak), Actions (e.g. merge-me), other products (e.g. renovate), a cron job that just runs npm update every day, etc.
This just feels like security by obscurity to me. So far, I was using an auto-merge action and while implementing it I was a bit annoyed that it's so complicated, but never thought about security concerns. That's probably also the case for many other developers that just want the feature and that not think about why it is not provided out of the box. In my opinion, it would create a much better awareness, if dependabot has a "automerge: true" feature and the documentation would discuss pro and cons of using it. Maybe couple it to an option "allow-unsafe-operations: true" or something, to make it really clear!
Relying on 3rd party actions to do auto-merge opens up another attack vector: Merging of non-Dependabot pull requests. If someone manages to create a user account that somehow matches the fragile string search for dependabot that 3rd party solutions require, they can easily submit pull requests on all repositories using the same matching algorithm and have their attack automatically merged. The attack would then not only be limited to dependencies, but to the actual code in the repository as well.
Even with a cryptographic signature-based solution (see #1973 (comment)), bugs will occur in 3rd party actions that may open up this attack vector. Actions are dependencies as open to bugs as any other dependency, after all. Therefore, the fewer dependencies, the better.
I used the dependabot auto-merge feature for a long while and was sad when it went away. My workaround is to schedule all of the dependabot updates for Tuesday mornings, and copy/paste @dependabot merge between GitHub email notifications. I don't mind this so much.
My hunch would be: the majority of maintainers don't review every line of change in their dependencies. At most, they look at the release notes. So, really the difference is:
- Life before dependabot: dependencies rarely were updated.
- Life with dependabot: dependencies are semi-regularly updated.
This hypothesis could be validated with a survey and some data analysis.
If this were true, it almost presents an argument in @asciimike's favor: longer delays in updating dependencies makes a supply-chain attack is less acute.
Ultimately, it's tough because official support for auto-merging dependencies presents a huge ball of liability for GitHub. This liability exists because open source is really only a web of trust. Auto-merging dependencies would allow a nefarious actor to violate the trust faster, more severely, etc.
Ultimately, it's tough because official support for auto-merging dependencies presents a huge ball of liability for GitHub. This liability exists because open source is really only a web of trust. Auto-merging dependencies would allow a nefarious actor to violate the trust faster, more severely, etc.
Yep, that's exactly our thought process. We have some exciting plans to improve this within the part of the organization that Dependabot is a part of, and once we've solved this or at least part of it, we'd love to revisit the decision.
That's really a sad move from Dependabot even if I understand the arguments for and against the auto-merging removal.
At work we have more than 200 repositories (with a lot of private ones) and we can not check ALL Dependabot pull requests accross all of them.
The auto-merging feature is so much useful that we literally can't think working without it:
- it saves us a lot of times
- we configured Dependabot to merge patch and minor updates, meaning we can take benefits of fixed bugs or improved perfs (but of course it can also comes vulnerability issues, but since we only have web projects we don't really care (don't hit me 😝 ))
Of course there are many tools that can automatically merge (and auto-approve if needed), like Kodiak, but to be honest I found it hard to understand and use. Also I'm not a big fan to delegate auto-approving/auto-merging to a third-party tool, where Dependabot (owned by GitHub) did the job perfectly before.
I can 100% trust Dependabot, which is not the case for third-party tools. I don't say they are bad and can't be trusted, I'm an open-source contributor and really like open-source, but that's not an official GitHub feature.
As a workaround, I've created a GitHub action that fits our needs https://github.com/Yproximite/auto-approve-and-merge-dependabot-action:
check it's a PR from a dependabotcheck update type (thanks to #1973 (comment))approve and merge if the update type is allowed to be merged
EDIT: prefer using https://github.com/ahmadnassri/action-dependabot-auto-merge which do the same things but better! :D
It does the job (even if sometimes I got random 403 error from GitHub API), but that's definitly not ideal. 😞
Won't it be possible to keep auto-merging feature but make it disabled by default?
EDIT 2: See https://hugo.alliau.me/2021/05/04/migration-to-github-native-dependabot-solutions-for-auto-merge-and-action-secrets/ for a working example of auto-approve and auto-merge.
Similar to the point raised in #1973 (comment)
To me at least, there's a bit of a conflict between (paraphrasing)
"auto-merging is too risky to be a core part of github / dependabot"
and the suggestion that
"Several 3rd-party GitHub Actions and bots [untrusted code, from untrusted devs] can replicate the automerge feature. [by allowing them access to PATs that have full control over the repo]"
I can understand how it reduces the legal liability faced by Github, but people looking to keep their current workflow will actively be making themselves less secure.
Ideally github / dependabot presents information about risk to me & I explicitly make an informed choice about what the acceptable trade off for me / my organisation is.
@asciimike 's comment about labels (#1973 (comment)) makes a lot of sense, if dependabot added labels like new maintainer / minor dev dependency patch / package from your own organisation- then I was able somewhere else in github to say at an organisation level "automerge without approval if user is dependabot & labels have X but not Y".
Since trying to manually keep all 318 of our repos up to date is just slow manual "automation" but with the responsibility shifted to whoever is unlucky enough to be skimming over the big list of dependabot PRs and clicking merge without reading them.
The PATs needed to make third-party solutions work also cannot be limited by repository, so if I choose to use one for my personal projects, I also expose all organisations that I'm a member of to any security problems with those third-party solutions.
My comments are never intended as condescending, and I apologize if they came off as so
@asciimike after thinking about this I believe this is the core of my frustration here. You don't trust me to make good choices for my own application. Automerge was already opt in so there is no risk that I could enable this feature accidentally and the "folks who are not in this thread" you're worried about would also have to opt-in to that behavior. The entire argument from the Github side is that developers cannot be trusted to make good security tradeoff decisions and so you have stepped in to save us. I asked for more labels almost a year ago in #2294, that is a possible solution that may help with this. More improvements to the new Enable Auto Merge option in the PR UI will also help. At the end of the day though I'm going to have to cobble together a solution that you could continue to provide, but are refusing to.
Leaving the decision of what package to be merged instead a human being it is the same.
If you have a compromised npm repository that contains a virus... If you are a human you will end up merging the PR as well and being compromised.
So your suggestion basically it is not to update packages what it is so weird because why make a bot for updates in the first place?
I don't see why automerge feature is less secure than a human making the same mistake than a bot.
I would like to have this feature under a big disclaimer and A I_KNOW_WHAT_I_AM_DOING disclaimer type of thing.
The discusion about compromised repositories ends up in dont have trust on any package on npm and therefore dont update any package what makes this bot totally discouraged.
I think that a proper CVE announcements... automerge of CVE mitigations and even automerge a downgrade version on compromised repositories it is better than non supporting this feature at all.
Sorry if I said something stupid because my knowledge about security is very limited.
Thanks.
TLDR; limit the scope of automerge feature only to CVE mitigations.
I recognize that for some of you, nothing short of
automerge: truewill make you happy.
I don't think that's quite true. The issue, as I see it, is that GitHub/Dependabot hasn't taken on the development and documentation burden here. We aren't being told "if you want to setup automerge, add the following workflow which invokes actions/dependabot-merge@v1".
There is no clear, singular, and correct solution for this problem being offered up by Dependabot.
Where there was one vendor and one software solution before, we now have multiple vendors. We have to evaluate how much we trust them, how much it's worth learning a new toolchain, etc.
As a project maintainer using GitHub, I already have to trust GitHub. If I add another tool -- kodiak, renovate, etc -- then I'm trusting that maintainer with the relatively powerful and risky action of automatically merging PRs.
The reason a lot of people here have some frustration is this line in the migration doc:
For those of you who have vetted your dependencies, or are only using internal dependencies, we recommend adding third-party auto-merge apps, or setting up GitHub Actions to merge.
The guidance is incomplete and leaves finding a concrete solution "as an exercise for the reader". It might have been better for GitHub to have said nothing at all.
I'm trying to figure out what to do, and, in my case, I'm going to suggest to my co-maintainers that we just wait and see.
Dependabot is still offering me plenty of value, and as others have said it's not a huge problem to manually merge the PRs. I think some people are losing their heads a bit about how much of a pain that turns out to be; it's not fun but it's totally fine.
I've replaced dependabot with renovate bot, and I can recommend everybody interested doing the same. I don't know what was so difficult in renaming automerge: true to i-know-what-im-doing-and-understand-the-risks-so-automerge-please: true and keeping perfectly valid feature, but it's no longer any concern of mine.
The fact that you've decided to announce the shutdown of native Dependabot before resurrecting this feature as part of your "investigation" in #1823 (comment) was the final nail in the coffin for me. Defending your decision with that argument yet recommending people to use third-party solutions to re-enable automerge is a total hypocrisy to me.
So long dependabot, yet another great product that went downhill after acquisition.
As a practical solution, I made a simple script that I can run locally that uses the GitHub API to find relevant pull requests and add a @dependabot merge comment. Because it runs locally I don't have to give my PAT to any third party.
Following #1973 (comment), this is how I was able to re-implement auto-approve and auto-merge Dependabot pull request (only patch and minor updates) and after the CI becomes all green:
https://hugo.alliau.me/2021/05/04/migration-to-github-native-dependabot-solutions-for-auto-merge-and-action-secrets/
I just to want to voice my opinion too. I totally agree that the way this has been handled is very bad. Suggesting to use external tools to get the auto-merge feature is a contradiction.
Thanks @asciimike for your genuine curiosity and empathy in presenting the reasoning in public here, knowing that a great many users and customers will see this as very bad news. We still appreciate you! ❤️
As Github Team customers, however, I do think it's important to clarify that we consider having a narrow, security-maximizing native support for auto-merging to be vital. For example, an auto-merge dependabot feature that narrowly allows only:
- allow-listed dependencies
- passed all CI tests
- semver patch version change
- with no change of control over the dependency (if possible)
Q: Is it clear why we are seeing this feature gap as squarely in the middle of the target for the "Github Advanced Security" product value?
For reference, this text is from the doc "Github Enterprise Grade Security and Compliance":
Dependabot & Automated Security Fixes (Beta)
Automated maintance [sic] of vulnerable and out of date
dependencies• Automated pull requests with changelogs, commits,
and compatiblity [sic] scores for outdated dependencies• Resolve vulnerabilities using an automated
security fix in a pull request that corresponds to
security alerts
We do see this feature advocated heavily towards our organization as a reason to upgrade to GHE -- does that framing make sense?
I think my current thought is that we'll provide as much metadata as possible (either as labels or as YAML embedded in the PR body) and have that feed into an Action that can enable GitHub's automerge, so folks can perform whatever checks they'd like.
Note: we haven't committed to this design, but I think it's directionally accurate
For example, I could see something like:
name: Dependabot auto-merge
description: Enable GitHub Automerge for patch updates on `bar`
on: pull_request_target
permissions:
# scope down as necessary here
jobs:
dependabot:
if: github.actor == 'dependabot[bot]'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata
# outputs = {dependency_name: foo, dependency_type: development, update_type: version-update:semver-patch, ...}
- name: Enable auto-merge for Dependabot PRs # respects checks and approvals
if: ${{steps.metadata.outputs.dependency_name == "bar" && steps.metadata.outputs.update_type == "version-update:semver-patch"}}
run: gh pr merge --auto --merge "${{github.event.pull_request.number}}"
env:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}Thanks for this @asciimike! In principle, it seems as though the direction you outlined above would work in a "roll your own" fashion 🚀
Crucially: the proposal above does not require trusting third-party actions!
I wonder if there is perhaps a PM we should be in touch with, in terms of understanding how we see this product feature interacting with messaging we are receiving around the product? I'm not hearing the centrality of this feature to the product offering being acknowledged in this thread, perhaps I missed it?
May I ask that our kind friends at Github also review how the Supply Chain Security is actually being marketed to clients like us? It still seems to me that there may be a disconnect between the outward-facing messaging from Github, vs the content of this thread.
For example:
Enabling and disabling version updates
You can configure your repository so that Dependabot automatically updates the packages you use.
Thanks again!
That PM is me.
It sounds like the issue is that you view "automatic upgrades" to be "zero action taken" (where does this end? The manifest file? Or should we deploy the dep to prod for you too?) while I think the current view taken by Dependabot is that the scope ends when we create the pull request. If we changed the language to be, "You can configure your repository so that Dependabot automatically creates pull requests to update packages you use" does that clear up confusion?
IMO, the difference between "enable a config in a dependabot.yml" and "add an action that basically does the same thing" is fairly minimal overhead wise but significantly more customizable from a developer perspective. It also plays nicer with existing functionality, e.g. we don't have to build an automerger that's constantly at odds with how GitHub's automerger works--we just allow devs to chain the functionality together.
Our goal is to provide a set of first party primitives, upon which folks can build whatever functionality they want.
Oops, thanks @asciimike! I sincerely apologize for not realizing you were the PM on this. Thanks for your work, Dependabot has been a huge help to us, as has Github itself.
Please let us know if there might be an opportunity for us to contribute our client perspectives on this, beyond this public thread.
It's all good. Since support will hopefully direct you back to threads like this, feel free to email me at my username at github dot com.
I'd be very happy with that notion about putting extra information into labels / a structured format in the PR.
It'd help both people who want to keep the auto-merge and those who'll be doing it manually - you could filter PRs just to labels you reckon are probably safe and look through them quickly vs taking more time to look at larger / riskier changes.
(I'd be more happy if there was an easy way to DRY up that workflow / action so it wouldn't have to be duplicated & maintained across repositories, but I gather that'll be coming at some point)
(I'd be more happy if there was an easy way to DRY up that workflow / action so it wouldn't have to be duplicated & maintained across repositories, but I gather that'll be coming at some point)
The Actions team hears this loud and clear: github/roadmap#98
Hi @asciimike , I tried something similar to your recommendation in one of my projects.
The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.
I believe this is some sort of issue with the new GitHub auto-merge functionality. Is there any way to direct this issue to the correct teams at GitHub?
The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.
I think this might be expected behavior. The Actions token expires as soon as the workflow ends.
At the point in time when the branch is merged, the token is expired and cannot delete the branch or close the PR. I had the same problem.
Or you might be right here and this is bug and not expected behavior.
If you want to work around that issue, you would be able to create a different workflow that triggers once the "test/build" action on the PR is completed. My code at the moment looks like this:
---
name: "Pull Request Auto Merge"
on:
workflow_run:
workflows: ["Syntax and Lint"]
types:
- completed
permissions:
contents: write
pull-requests: write
jobs:
Dependabot-Automerge:
runs-on: ubuntu-latest
# Contains workaround to execute if dependabot updates the PR by checking for the base branch in the linked PR
# The the github.event.workflow_run.event value is 'push' and not 'pull_request'
if: >-
github.event.workflow_run.conclusion == 'success'
&& github.actor == 'dependabot[bot]'
&& github.event.sender.login == 'dependabot[bot]'
&& github.event.sender.type == 'Bot'
&& (github.event.workflow_run.event == 'pull_request'
|| (github.event.workflow_run.event == 'push' && github.event.workflow_run.pull_requests[0].base.ref == github.event.repository.default_branch ))
steps:
- name: Approve Changes and Merge changes if label 'dependencies' is set
uses: actions/github-script@v4.0.2
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
var labelNames = await github.paginate(
github.issues.listLabelsOnIssue,
{
repo: context.repo.repo,
owner: context.repo.owner,
issue_number: context.payload.workflow_run.pull_requests[0].number,
},
(response) => response.data.map(
(label) => label.name
)
);
console.log(labelNames);
if (labelNames.includes('dependencies')) {
console.log('Found label');
await github.pulls.createReview({
repo: context.repo.repo,
owner: context.repo.owner,
pull_number: context.payload.workflow_run.pull_requests[0].number,
event: 'APPROVE'
});
console.log('Approved PR');
await github.pulls.merge({
repo: context.repo.repo,
owner: context.repo.owner,
pull_number: context.payload.workflow_run.pull_requests[0].number,
});
console.log('Merged PR');
}This workflow is triggered once the "Syntax and Lint" action is completed successfully. The "auto-merge" (not GitHub auto-merge functionality) is only executed if the commit is created by the dependabot.
At the point in time when the branch is merged, the token is expired and cannot delete the branch or close the PR.
That's an interesting thought! I think it's probably still a bug since the auto-merge was enabled at the time the credentials were valid and the merge does actually complete.
If the credentials were required for merging after the workflow, I would think the merge wouldn't succeed at all instead of having partial success.
The result is that the PRs do get merged into the main branch automatically, but the PRs don't seem to close on merge.
I believe this is some sort of issue with the new GitHub auto-merge functionality. Is there any way to direct this issue to the correct teams at GitHub?
It is a known UI display issue, and we're tracking it internally. Sorry about the confusion :(
Thanks for the feedback and sorry for the confusion here.
Auto-merge will not be supported in GitHub-native Dependabot for the foreseeable future. We know some of you have built great workflows that rely on auto-merge, but right now, we’re concerned about auto-merge being used to quickly propagate a malicious package across the ecosystem. We recommend always verifying your dependencies before merging them.
The number of emojis of thumbs down is speaking what the users want! dependabot is an amazing tool and we are so excited for it to be natively part of github. however, it is missing this basic workflow of auto approval. basically, engineers want to put dependency management on "auto-pilot" as much as possible. Let them make specific choices on security them selves :)
@mathiasrw re: #1973 (comment)
Per: https://github.com/settings/admin:
Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.
the [ character is thus reserved.
If you're concerned, you could check the nodeid / user number or also check the bot property...
@mvz re: #1973 (comment)
If a tool supports ssh, you could use ssh deploy keys on a per repository basis instead of PATs. I'm not saying you should, but, you could. They aren't quite as granular, but they're a thing.
Alternatively, you could create a user per repository and make it a member (or similarly assign permissions for the repository), and then create a PAT per user-repository, e.g.: org/repo => @org-repo-bot. Obviously that wouldn't be enjoyable for a large number of repositories, but again, it's a theoretically possible implementation.
@jsoref indeed, I am using the bot user + PAT pattern for, e.g., accessing other repositories from CI. It is the only combination that provides the right granularity for me. I just wish regular PATs could be limited to a set of repositories.
@asciimike I just want to be clear, because on the dependabot preview settings page under installed GitHub apps, it expressly calls this out as a feature that is supported:
See the bottom section. If this issue is to be believed that is not at all accurate. It cannot be configured to automatically merge when checks pass in any meaningful way.
I can type @dependabot merge but that's not what is being described there. How do I reconcile that?
@knechtionscoding the dependabot preview app has different features from the github-native version.
Correct. Dependabot Preview has been deprecated since April and was shut down on August 3rd. We are in the process of uninstalling the Preview app from repos across GitHub, so that page will disappear soon.
Folks, if the decision of disabling auto-merge is final and won't be changed in the nearest future, please close this issue and add some notification to the docs.
The current behavior is very confusing ( for one repo it does work, and for another - no) and reading of this topic doesn't really help to understand what's going on.
Interacting with dependabot would be a lot smoother if the @dependabot user would be autocompleted. I'm having to type the whole thing manually to give it a command and it's starting to become annoying.
Interacting with dependabot would be a lot smoother if the
@dependabotuser would be autocompleted. I'm having to type the whole thing manually to give it a command and it's starting to become annoying.
Thanks, that's good feedback I've definitely felt this myself. I'll raise this internally and see if there's something in the roadmap more broadly for bots to be autocompleted in mentions 👍
In case anyone stumbles across this issue.
The official GitHub Docs now document a process for Dependabot auto merge here.
Sadly, it looks like the fetch-metadata-action is not getting a lot of attention.
How do we disable auto-merge until our CI integration workflow completes? Auto-merge doesn't seem to block on this currently.
@Kurru you can also add a branch protection rule that requires status checks to pass. That way, you can also require non-GitHub Actions CI runs to be successful.
Those options are kinda workable though not great. We are a tiny company with a mono-repo and we don't want branch protections, but would really like to auto-submit dependabot pull requests if they pass our CI. Adding to the CI workflow isn't terrible, though we do have multiple CI targets that are impacted by certain pull requests (we use multi-project Gradle).
In general, our want for auto-submit is from our use of multi-project gradle. We receive redundant pull requests for each our our inner projects.
This kind of "auto-merge" workarounds are rather hacky and certainly not as intuitive to use or configure as renovate's baked-in automerge feature. Would really appreciate this being a "native" feature to dependabot as it was in v1.
I'm using the officially documented auto-merge workflow mentioned in #1973 (comment), and it works, but with an odd quirk. If I want it 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!
@snarfed:
Instead of having a standalone workflow set the auto-merge flag, integrate it into your normal workflows.
If you have a single workflow for the rest of your tests, you can use: needs.
If you have a bunch of them, you could have a workflow with workflow_dispatch that each check triggers which checks to see if everything has passed.
Not sure about the "official" way to do this, although, I'd support having something officially documented as it seems like a perfectly reasonable request.
From reading https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request, it appears that dependabot is seen as an admin and thus isn't really bound by the terms of auto-merge. Which would be why enforcing require checks for administrators results in auto-merge doing what you want. I think it's reasonable to have the documentation for that page also changed to clarify this (that dependabot is functionally treated as an administrator, and for the auto-merge to wait for checks would require the enforce checks for administrators option).
While what I've described is framed in GitHub Workflow terminology, you can do the same sorts of operations anywhere.
https://discuss.circleci.com/t/run-another-workflow-after-a-workflow-succeeds/36294
Technically true!...but way more effort to build and maintain than I'd like.
Specifically, I only want to auto merge patch or minor version upgrades. Github Actions exposes this in the update-type metadata as version-update:semver-patch, -minor or -major. That's easily consumed in Actions, but in Circle, I'd need to write code that auths into the GitHub API and uses it to fetch that metadata. Ugh.
(I briefly searched Circle's public orbs for anything relevant that I could use, but I didn't see anything.)
FWIW, I also have a set up with CircleCI and the officially documented auto-merge workflow, and it works well without turning on "Include administrators" setting. I'm using the secrets.GITHUB_TOKEN token just like in the documented example.
Interesting: the auto merge behavior changed at some point in the last few days. My branch protection has "Include administrators" disabled, and when the github-actions bot enables auto-merge on a PR (via the workflow in the docs), GitHub now waits for CI to pass before merging. Example: snarfed/granary#298
Following up here, I may have misdiagnosed this initially. I'm seeing a different bug or odd behavior now, which was maybe also the root cause before.
It looks like auto merge is indeed waiting for the branch protection required checks to pass after all, even with "Include administrators" off. However, after the merge, it occasionally doesn't show that all required checks passed before merging.
snarfed/bridgy#1236 (comment) (screenshot below) is an example. The repo's branch protection on main requires the ci/circleci: build check to pass. Auto merge was enabled at 3:00p PT, most other checks ran within a few minutes, CircleCI finished and passed at 3:38:56p PT, and the GitHub UI says the PR was merged at 3:38p PT.
So it seems pretty like that Circle finishing triggered the merge. However, the GitHub UI says Circle hadn't finished when the PR was merged. I'm guessing this is a bug in the UI...?
(Yes, clock skew happens, but I doubt Circle's and GitHub's clocks were off by 30+m. 😁)
I agree that dependabot should not set auto-merge due to the security issues it raises. If you really know what you're doing and really want auto-merge, just use something like https://github.com/marketplace/actions/enable-automerge-action
For the sake of discussion, what's the difference between the security concerns of Auto Merge versus that of a human pressing Merge? Wouldn't the human be just as oblivious to new vulnerabilities in the updated dependency as dependabot? What if the repo already has required checks in place in the PR actions that run security scans?
An adult can read the source code changes for the dependency before merging the PR.
It's true that not all humans will be able to understand the changes, but a human could.
Also, if you wait a bit on a dependency update, it's possible that if there is a problem with the update, some other human will report about it in a place the human could discover it.
A baby just tapping on buttons and triggering a merge without understanding the consequences of their actions otoh is dangerous. They're cute 👶, but dangerous if left unattended.
If the reason this isn't added is because of security concerns, couldn't there be an option to delay dependency updates by some amount of time, e.g. 1 month after release, so that new dependency updates are at least a month old and can be safely auto-merged?
Depfu has an option similar to this: https://docs.depfu.com/article/36-reasonably-up-to-date
🍿
An adult can read the source code changes for the dependency before merging the PR.
It's true that not all humans will be able to understand the changes, but a human could.
@jsoref I see your point, but (at least in my experience) nobody checks the source changes of their upstream deps anyway. Though we can (and probably should), we don't.
I don't know. It's something to consider. 🤷
@jsoref I see your point, but (at least in my experience) nobody checks the source changes of their upstream deps. Though we can (and probably should), we don't.
I don't know. It's something to consider. 🤷
Is this an argument against auto-merging, or against updating third-party dependencies in general?
Sorry if that wasn't clear @shepherdjerred. I was responding to @jsoref's comment above, which says we shouldn't allow auto-merging because humans should always have an opportunity to review dependency changes before merging.
(I've edited my previous comment for clarity.)
Thank you for clarifying :)
As an aside, I've setup Dependabot auto-merging with a simple GitHub Action, though I would still like to see this as a native option for Dependabot.
name: Dependabot auto-merge
on: pull_request
permissions:
pull-requests: write
contents: write
jobs:
dependabot:
runs-on: ubuntu-latest
if: ${{ github.actor == 'dependabot[bot]' }}
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@v2.1.0
with:
github-token: "${{ secrets.GITHUB_TOKEN }}"
- name: Enable auto-merge for Dependabot PRs
run: gh pr merge --auto --rebase "$PR_URL"
env:
PR_URL: ${{github.event.pull_request.html_url}}
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}