"Upcoming Dependabot comment command deprecations" feedback

[qgustavor]

Select Topic Area

Product Feedback

Body

Related GitHub Changelog post: https://github.blog/changelog/2025-10-06-upcoming-changes-to-github-dependabot-pull-request-comment-commands/.

My feedback: I'm an avid @dependabot merge user so, of course, I don't like this. Commenting on the arguments, "reduce confusion" makes sense because "why the bot handles that?", and "improve reliability" makes sense because it wasn't the bot's job in the first place, separation of concerns is important. I don't get the "encourage use of the GitHub platform’s built-in tools", why? People using the command surely knew they would use the tools, it was just other way to do.

Then, it makes me think: why people using those commands use them? In my case, because it's a way of quickly merging dependabot's PR's within my e-mail client without I having to open GitHub. I guess some people probably even automated this step and made automatons to reply dependabot's mails with @dependabot merge, because, let's be fair, I never check if their PR's will break things and that's why some of my projects I don't have time to maintain have their CI's broken.

But, again, separation of concerns is important, so I guess the issue here is: why people are using those commands in the first place?

If people are using it because e-mail, then GitHub could make those commands work via e-mail for any PR, not just dependabot's. If people prefer a text interface (for whatever reason), it could be implemented in a way that still allows for separation of concerns. Other people can give their feedback on this thread, of course.

Considering how my feedback on the automatic watching of repositories went (it got ignored, the feature got deprecated and I know at least two developers that had issues because of this) I don't expect this deprecation to be reversed, so I will disable dependabot from my projects, as it's annoying to having to open GitHub just to approve PRs that often only fixes issues that don't affect my projects. As my FOSS projects are mostly static websites hosted on GitHub Pages, fixing any vuln with "Attack Vector = Network" is often just a matter to "ok, let's fix it so npm stop whinning whenever I do npm install".

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[pglombardo]

I would simplify and just say that I've relied on this functionality for years and it has always worked flawlessly. It's been an important part of code workflows to automatically merge security issues and minor dependency updates.

I don't understand the reasoning to remove it because none was shared and to add, no alternative was provided.

"Please update your workflows to rely on GitHub’s native features" I thought this was a native feature...

The way this change has been communicated makes the removal seem senseless and without valid motive.

[felsokning]

"This change is intended to reduce confusion, improve reliability, and encourage use of the GitHub platform’s built-in tools for working with pull requests."

This statement comes across as a problematic for a myriad of reasons. Let's break them down:

1. Reduce confusion - Is the inference that users who use these commands don't understand what they do, so GitHub has to intervene on behalf of "confused users"? Squash and merge, a setting that you can apply to the default behaviour of a pull request - for example, doesn't use any language or contextual information that's any different than actually configuring a pull request to always be squashed and merged. So, the question becomes, because this is the vernacular that you've specifically chosen to use, how is there confusion introduced when the words/meanings are the exact same thing? Is the inference that users get confused about what a merge versus a squash and merge and the like are? If so, wouldn't the issue actually be the vernacular chosen for the PR merge types and not the commands, themselves? In other words, the specific vernacular you've chosen is pretty damning because it infers that the users who use your bot get confused around the commands, which happens to use the same vernacular/language/wording of the pull request behaviours. How can users get "confused" in one context but not another?
2. Improve reliability - Removing a feature does not improve the reliability of that feature or the reliability of the overall product. It merely reduces your responsibility of supporting that feature to nothing and, thus, the only "improvements to reliability" are the areas of the code you now have to touch to support the dependabot. For example, taking "squash and merge" as command, if the squash and merge via the PR UI is broken, you've actually reduced the surface that can be used to achieve this goal; so, if anything, you're actually making reliability worse - not better. Feel free to correct me, if I'm wrong. Worth noting about reliability is that the documentation for the commands hasn't been changed for this deprecation. So, in about a month's time, your own documentation will give this commands that the bot will no longer support.
3. Encourage use of the GitHub platform’s built-in tools for working with pull requests - This seems to be the penultimate reason for this change. Some PM saw that the use of the web interface was actually going down because of the use of the bot commands and decided that this wouldn't do, because the "impact" is driving downwards on the use of their features and, thus, they've lost a key metric for their end of the year reviews. Given that dependabot is a bot written by Microsoft and is one of Microsoft's "built-in tools" to be used on GitHub (literally have documentation on Github for this specific bot versus, say, renovate) this seems to cause a cognitive dissonance around "encouraging built-in tools" because you're saying one built-in tool > than another. If the focus is on GitHub's "built-in tools" (herein, meaning the UI, so far), why wouldn't the assumption be that you're eventually going to scrap dependabot altogether for some AI integration, in the future, and that we shouldn't just dump the bot, entirely, now? After all, the features of a built-in tool for GitHub (dependabot) are being deprecated for features of another built-in tool (the PR UI), which doesn't imply/infer these sorts of deprecations will stop here - so long as someone else gets a say/control over your team's features.

I really hope that this statement is just the result of poor wording by someone who's unfamiliar with the tool and it's use because, otherwise, it comes across as pretty condescending and tone-deaf to the actual users of the bot.

[WIStudent]

GitHub’s built-in merge tools are not an adequate replacement for @dependabot merge in my opinion. With @dependabot merge I can review multiple dependabot PRs, add @dependabot merge comments to the ones I want to merge, and leave the actual merging and rebasing to dependabot. With GitHub's merge tools, merging one dependabot PRs often causes merge conflicts on other Dependabot PRs (because of changes to files like package-lock.json), so once I merged one PR, I have to wait for dependabot to rebase the other PRs (or tell it to do it with @dependabot rebase) before I can merge the next dependabot PR.

[slifty]

I opened a related discussion here: dependabot/dependabot-core#13266

I'll add another example use of the merge command, which I mention in that discussion:

I had been relying on @dependabot merge to help protect my projects from dependabot phishing attacks on my repository -- the logic being that if someone attempts to credibly APPEAR as dependabot opens a PR, and I fail to detect that spoofing in my review, @dependabot merge would be a final safeguard because the attacker would not have the rights to merge.

Another use case: My repositories require an approval (including dependabot). The flow I had used was "review code, approve, and include @dependabot merge in my approval message).

With this change I'll need to approve, then go back to the ticket and manually merge (or I'll need to click the big "bypass branch restrictions" button which is a habit I NEVER want to get in as it risks accidentally bypassing other restrictions such as CI.

[slifty]

I was hoping that auto-merge could help, but it looks like even then I'm going to have to manually handle the need for rebase. Here's an example PR state which I am going to have to manually babysit (imagine there are 5 dependabots that need merging). If I used @dependabot merge then dependabot would handle cascading rebase triggers.

[brooke-hamilton]

I use @depenabot rebase a lot. Having to do a manual rebase is not an improvement, and potentially makes it more difficult for me to get the PR merged, because after I push a rebase then I'm a PR author and I have to get someone else to approve it. If I use @dependabot rebase, I can approve it myself.

[slifty]

From the article it does look like @rebase is NOT on the list of deprecated commands.

[brooke-hamilton]

Thank you! Either I misread it or the list has evolved.

I wonder what they plan to do with @dependabot reopen. That's another one I have used frequently when other changes supersede some of the changes made in the dependabot PR.

[SvenStaehs]

Do you mean @dependabot recreate? Because reopen simply re-opens a PR that you've closed (and removes the resulting ignore-rule).
There is a "GitHub native" button to re-open a PR and Dependabot will treat that just like a reopen command (by removing the ignore-rule). Just like Hitting the "Close" button is identical to @dependabot close command, but will add that rule, so both commands can be replaced by pressing the button.

recreate on the other hand is indeed very useful if someone manually meddled with the branch, and is not scheduled to be deprecated. At least as per the current content of the blog post:

@dependabot merge
@dependabot cancel merge
@dependabot squash and merge
@dependabot close
@dependabot reopen

[pglombardo]

After thinking about it for a while, if they remove these commands, it just might be time to find a 3rd party alternative. There are a bunch... many free for OSS.

[SvenStaehs]

Yeah, I have the same use-case of "review code and finish it with @dependabot merge command" workflow, and will be sad when that gets removed. Maybe there's an option somewhere that allows auto-merging non-draft PRs when all requirements are met, including approval, so then the approval itself would trigger the merge.
Or maybe we'll get another bot that will replace merge-related features of Dependabot? PRbot? Then it could be used for other PRs as well (hopefully configurable).

For the workflow of "approve multiple PRs and let the bot handle the rebase-merge cascade", I was hoping merge queues to help with that. But I've not tried it yet, and simply rebasing the PRs will not work due to conflicts, so it might not work.
It's possible the merge queue can trigger a @dependabot rebase instead of simply git rebaseing the PR. If that's the case, then I agree that there's a GitHub native feature that replaces rebase and merge.

[slifty]

I hopped on a call with the dependabot product lead last week (they have open office hours, which is neat!)

I explained our process, how CI has to pass and PRs need approval before merge. Given all of those constraints she recommended we check out this GitHub Action which sets dependabot PRs to auto-merge: https://docs.github.com/en/enterprise-cloud@latest/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#enabling-automerge-on-a-pull-request

We haven't tried it yet, but if it works then I think that would align with our existing flows (with the added benefit of not needing to type an explicit merge command).

[huehnerlady]

I use it a lot as well. For me it is important to still look at the PR, but having to review every PR AND then merge it are 2 steps. With this command I can minimize it to 1 step.
And yes, it is not a lot of time I save per PR, but when you have to go through 30+ PRs at once it is a huge time saving.

I am hoping that they might introduce a config flag that enables the github built-in auto-merge flag. That way you would just need to review the pr and then the github build in auto merge would kick in.

I appreciate that processing a comment and acting accordingly is a complexity that is not needed, but I also feel that an alternative to save time should be able to be done.

As a workaround you can create a github action that sets the auto-merge flag on PRs, but that feels very hacky and also additional overhead as you have to maintain this github action in every repository - especially if dependabot is creating the PR anyways.