Turn a Pile of Dependabot PRs into One

Group routine Dependabot bumps into one PR and keep security fixes fast.

Introduction

30 Second Summary

You open your project on Monday and a dozen notifications are waiting, each one nudging you to update a single package. By the third one you have stopped reading them.

In this project, you will set up that flood on purpose in a repo you own, then rewrite one Dependabot config file to tame it. Routine version bumps arrive as a single pull request on a slower schedule, while security fixes still come through on their own.

What You'll Build

You will watch a wall of one-package pull requests collapse into a single grouped pull request whose body lists every package it bumped.

By the end of this project, you'll have:

A public repository on GitHub with deliberately outdated packages, so you can summon the pull request pile on demand and see the noise for yourself.
A working dependabot.yml you can drop into any repo unchanged, carrying a groups block, a monthly schedule and a second ecosystem entry.
One grouped pull request merged into a single commit that changes every dependency version at once, plus proof that your security updates still arrive on their own fast track.
Secret Mission: Split your grouping in two so major version bumps land in their own pull request instead of hiding inside the routine batch.

Are there any prerequisites?

You need a free GitHub account and a browser. Dependabot version updates and security updates are free on public repositories, so this project costs nothing to run.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. Dependabot noise is easy to complain about and harder to actually fix, so naming the goal now keeps every config change ahead purposeful.

Create Your Practice Repository

Dependabot opens one pull request for every outdated package it finds. To feel that flood for yourself, you first need a repo whose dependencies are genuinely behind.

You'll build that repo from scratch on GitHub. Five popular npm packages, pinned to versions from one to two years ago, is plenty to set off a pile of pull requests in the next step.

In this step, get ready to:

Create a public GitHub repository to practise in.
Commit a package.json that pins five npm packages to old versions.
Confirm those outdated versions are live on your default branch.

Create a public repository on GitHub

In the browser tab where you're already signed in, go to github.com/new.
Enter dependabot-practice in the Repository name field.
Select Public for the visibility.
Tick Add a README file.
Click Create repository at the bottom of the form.

GitHub drops you straight onto your new repository page, with a single README.md file listed and a Public label next to the repo name.

Why does this repo need to be public?

Dependabot version updates and security updates are free on public repositories, so nothing here touches a card.

A public repo also means the Dependabot alerts you'll look at later are switched on for you by default.

Add a package.json with outdated versions

Dependabot reads your dependency manifest to work out what is behind. An empty repo gives it nothing to complain about.

On your repository page, click Add file near the top right.
Click Create new file.
Enter package.json in the file name field at the top.
Define your five outdated dependencies by pasting this into the editor:

{
  "name": "dependabot-practice",
  "version": "1.0.0",
  "description": "A practice repo for taming Dependabot pull requests",
  "license": "MIT",
  "dependencies": {
    "lodash": "4.17.20",
    "express": "4.18.1",
    "axios": "1.3.4",
    "moment": "2.29.4",
    "react": "18.2.0"
  }
}

What does this file do?

The dependencies block is the only part Dependabot scans for outdated packages.
None of the versions have a caret in front of them, so each one is an exact pin rather than a range.
The five names are all heavily used packages, so newer releases definitely exist for every single one.

Click Commit changes... at the top right.
Click Commit changes in the dialog to commit straight to your default branch.

Your repository file list now shows package.json sitting next to README.md.

Commit button greyed out?

Check the file name field reads exactly package.json with no trailing space.
Check you pasted the whole snippet, including the closing } on the last line.

Why won't GitHub let me commit my package.json?

Check the pinned versions on your default branch

Before you open the file, which of your five packages would you guess has fallen furthest behind its latest release?

Click package.json in your repository's file list.

You should see all five versions with no caret in front of them: lodash at 4.17.20, express at 4.18.1, axios at 1.3.4, moment at 2.29.4, and react at 18.2.0.

✔️ Awesome, I've got everything!

Your practice repo is stale on purpose and ready for Dependabot.

ⓧ I'd like to double check the full code

Compare your committed file against this:

{
  "name": "dependabot-practice",
  "version": "1.0.0",
  "description": "A practice repo for taming Dependabot pull requests",
  "license": "MIT",
  "dependencies": {
    "lodash": "4.17.20",
    "express": "4.18.1",
    "axios": "1.3.4",
    "moment": "2.29.4",
    "react": "18.2.0"
  }
}

Why pin exact versions instead of using carets?

A caret range like ^4.17.20 tells npm that any newer 4.x release is acceptable, so the manifest never really looks out of date.

An exact pin locks the repo to one specific release. That guarantees Dependabot has something to bump, which is exactly the noise you want to see.

Your repo is now a convincing pile of stale dependencies. Next up, you'll switch Dependabot on and watch it open a separate pull request for every single package.

Turn On Dependabot Version Updates

Your practice repository now holds a package.json full of versions that are a year or two behind. Nothing is watching that file yet.

Dependabot is GitHub's built-in dependency updater. Switch it on and it reads your manifest, compares each package against the latest release, then opens a pull request wherever it finds a gap.

That default behaviour is the exact problem this project fixes. You turn Dependabot on the way most repositories have it, so you can watch the mess arrive before you tidy it up.

In this step, get ready to:

Commit a .github/dependabot.yml file with a single npm entry on a daily schedule.
Trigger Dependabot by hand instead of waiting on the schedule.
Watch a separate pull request open for every outdated package.

Create your dependabot.yml config file

Dependabot only wakes up when a repository tells it to. That instruction lives in one file at a fixed path, .github/dependabot.yml.

Return to your practice repository on GitHub.
Click Add file above the file list.
Click Create new file.
Type .github/dependabot.yml into the file name field.
Give Dependabot its instructions by pasting this into the editor:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

What does this config do?

version: 2 is the config format Dependabot expects. Every config file opens with it.
package-ecosystem: "npm" names the package manager to read. Yours is npm because your manifest is package.json.
directory: "/" points at the folder holding that manifest, the top level of your repository.
interval: "daily" sets the cadence. Dependabot goes looking once a day.

Click Commit changes in the top right.
Click Commit changes again in the dialog to commit straight to your default branch.
Confirm the file landed by opening the .github folder in your repository's file list.

You should see dependabot.yml sitting inside that folder.

No .github folder in your file list?

GitHub builds folders from the slashes in the file name, so the name field has to read .github/dependabot.yml in full, leading dot included.
Check the extension is .yml and not .yaml, which Dependabot ignores.
If the commit dialog offered you a new branch, the file is not on your default branch yet. Commit it directly to the default branch instead.
My dependabot.yml file is not showing up in my repo.

✔️ Awesome, I've got everything!

Great, double check your commit landed on the default branch and carry on.

ⓧ I'd like to double check the full code

Here is the whole file as it should look right now.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

Run Check for updates from the Dependabot page

A daily schedule means Dependabot could take up to a day to notice your stale versions. GitHub gives you a button that runs the same check right now.

Click the Insights tab at the top of your repository.
Click Dependency graph in the left sidebar.
Click the Dependabot tab.

Your npm entry is listed here with the schedule you just committed. Before you trigger it, make a guess: your manifest pins five outdated packages, so how many pull requests do you expect?

Run the check now by clicking Check for updates next to your npm entry.

The check takes a minute or two on a manifest this small. Refresh the page until the entry reports it has finished.

No Dependabot entry on this page?

Dependabot only reads the config from your default branch. If you committed to a side branch, merge it in.
YAML is indentation sensitive, and a broken file is skipped quietly. Compare your file against the double check tab above, space for space.
The Dependabot page keeps a log for each check. Open the most recent one to see what Dependabot made of your config.
Why is Dependabot not picking up my config file?

See the pull request flood

Click the Pull requests tab at the top of your repository.

Dependabot has opened its own pull request for each outdated package it found. Every one carries its own title, its own one-line diff, and its own review to sit through.

Why one pull request per package?

Out of the box, Dependabot treats every version bump as its own separate change. Five stale packages means five branches, five pull requests, and five sets of checks to wait on.

That is defensible on a repo with two dependencies. On a real project it is the reason people stop reading Dependabot pull requests at all.

That wall of pull requests is exactly what makes teams mute Dependabot. Next up, you'll add a groups block that folds the whole pile into one.

Group Every Update Into One Pull Request

Your pull request list is exactly the problem this project is about. Dependabot found every outdated package in your package.json and opened a separate pull request for each one.

Each of those pull requests is a one-line version bump. Reviewing five of them costs five times the attention of reviewing one.

The fix is a groups block in your config. It tells Dependabot to bundle matching updates into one pull request instead of one each.

In this step, get ready to:

Count the separate pull requests Dependabot opened for you.
Add a groups block that matches every npm dependency.
Rerun the update check and watch the pile collapse into one pull request.

Count the noise you are about to fix

Before you change anything, get a number on the problem. That number is what makes the after state satisfying.

Return to your repository on GitHub.com.
Click the Pull requests tab.
Count how many open pull requests carry a dependencies label: your pull request count.

Every title reads like Bump lodash from 4.17.20, one package per pull request.

Why grouping instead of a pull request limit?

The obvious lever is a cap on how many pull requests Dependabot may open at once. That hides the backlog rather than shrinking it, because the capped updates just queue up behind the ones you merge.

Grouping changes the unit of work. Five bumps become one review, and the backlog is genuinely gone once you merge it.

Add a groups block to dependabot.yml

A group needs a name and a list of patterns. Anything matching a pattern rides in that group's single pull request.

Open the Code tab of your repository.
Open the .github folder.
Click dependabot.yml to open it.
Click the pencil icon in the top right to edit the file.

Your file currently ends on the schedule interval:

    schedule:
      interval: "daily"

Add the grouping rule by typing these lines directly below that interval line:

    groups:
      all-npm-dependencies:
        patterns:
          - "*"

What does this code do?

The groups key sits inside the npm entry, so it only governs npm updates.

The name all-npm-dependencies is yours to choose. It shows up in the grouped pull request title and branch name.

The pattern "*" matches every package name, so all five of your bumps land in the same group.

Check your indentation against the full file below.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    groups:
      all-npm-dependencies:
        patterns:
          - "*"

Click Commit changes in the top right.
Select Commit directly to the main branch.
Click Commit changes to save the file.
Confirm the commit landed by checking that dependabot.yml now shows the groups block when you view the file.

Your groups block is not showing up?

YAML is indentation-sensitive. The groups key must line up with schedule, four spaces in, not two.

Tabs also break the file. Use spaces only, which the GitHub editor does by default.

Still stuck? Why is my dependabot.yml indentation wrong?

Rerun the check and watch the pile collapse

Dependabot reads the new config on its next run. You do not have to wait for the daily schedule.

Return to the Insights tab of your repository.
Click Dependency graph in the left sidebar.
Click the Dependabot tab.

Before you click the check button, make a prediction. How many new pull requests do you expect this run to open?

Click Check for updates on the npm entry.
Wait for the check to finish, then open the Pull requests tab.

One new pull request appears, titled with your group name. Dependabot also closes the old one-package pull requests as superseded.

Open the grouped pull request.
Read the body and confirm it lists every package you pinned, from lodash through to react.

That single body is now your whole review. Five reviews became one.

No new pull request after the check?

Dependabot silently skips a config it cannot parse. Click the last update entry on the Dependabot page to read its log and see whether the run failed.

A run can also take a couple of minutes on a first grouped check. Refresh the Pull requests tab before assuming it failed.

Need a hand reading the log? Why did my Dependabot update run not open a pull request?

One pull request replaced the pile. Next up, you'll slow the cadence down to monthly and bring a second ecosystem under Dependabot's watch.

Slow the Schedule and Cover GitHub Actions

Your grouped pull request proved that one config block can collapse a wall of noise into a single review.

That group still rebuilds itself every single day. A repo you look at once a month does not need a fresh pull request waiting every morning.

Two edits fix the cadence and close a gap at the same time. You'll move the npm schedule to monthly, then add a second ecosystem entry so Dependabot watches your workflow files too.

In this step, get ready to:

Change the npm schedule interval from daily to monthly.
Add a second entry so Dependabot watches your GitHub Actions workflows.
Confirm both ecosystems and their next scheduled run on the Dependabot page.

Change the npm schedule from daily to monthly

Grouping decided how many pull requests you get. The schedule decides how often you get them.

Return to the Code tab of your repository.
Open the .github folder.
Click dependabot.yml.
Click the pencil icon in the top right of the file view to edit it.
Find these two lines under the npm entry:

    schedule:
      interval: "daily"

Replace daily with monthly, so the block now looks like this:

    schedule:
      interval: "monthly"

Click Commit changes in the top right.
Click Commit changes in the dialog to commit straight to your default branch.
Confirm the npm entry in the file view now reads interval: "monthly".

Why monthly instead of daily

A daily check means a grouped pull request can reopen or update every morning, whether or not anything meaningful moved.

Monthly turns routine version bumps into a scheduled chore you sit down and do. The pull request becomes something you read instead of something you dismiss.

Don't see your change in the file?

The commit dialog offers a new branch as well as the default branch. If you picked the new branch option, Dependabot never sees the edit, because it only reads the config on the default branch.

Check the branch name shown above the file listing matches your default branch.

Why is my dependabot.yml change not showing up?

Add a github-actions entry for your workflows

npm packages are not the only pinned versions in a repo. Every action referenced in a workflow file is pinned to a version too.

What is the github-actions ecosystem?

Dependabot treats each dependency type as its own package ecosystem, with its own entry in the config. Your npm entry only covers packages listed in a manifest like package.json.

The github-actions ecosystem covers the actions your workflows call. Without a second entry, those versions drift with nobody watching.

Click the pencil icon on dependabot.yml again.
Add this entry at the very bottom of the file, with its dash lined up under the existing - package-ecosystem line:

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

What does this code do?

package-ecosystem: "github-actions" tells Dependabot to watch the actions pinned inside your workflow files.
directory: "/" points at the top of the repo, which is where the .github/workflows folder lives.
interval: "monthly" gives the new ecosystem the same calm cadence you just set for npm.

Click Commit changes in the top right.
Click Commit changes in the dialog to commit to your default branch.
Confirm the file view now shows two - package-ecosystem lines under updates.

✔️ Awesome, I've got everything!

Great, your config is done. Double check the commit landed on your default branch before you move on.

ⓧ I'd like to double check the full code

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "monthly"
    groups:
      all-npm-dependencies:
        patterns:
          - "*"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

Config looks ignored?

YAML is indentation sensitive. The dash on your new entry must sit in the same column as the dash on the npm entry, and the three keys under it must be indented one level further.

A malformed config fails quietly. Open the update logs from the Dependabot page to see the parse error.

Why is Dependabot rejecting my config file?

Confirm both ecosystems on the Dependabot page

Before you look, how many entries do you expect the Dependabot page to list now, and what would tell you the monthly cadence took effect?

Return to the Insights tab of your repository.
Click Dependency graph in the left sidebar.
Open the Dependabot tab.

You should see two rows now, one for npm and one for github-actions. Each row shows the date of its next scheduled run.

Your open pull request is unaffected

The grouped pull request from the daily run is still sitting open, and the schedule change does not close or alter it.

The interval only governs when the next check runs. Leave that pull request where it is, you'll deal with it later.

Only seeing one ecosystem listed?

Dependabot reads the config from the default branch only. If your second commit went to a new branch, the page still reflects the single npm entry.

Reload the page after confirming the file on the default branch contains both entries.

Why is my github-actions entry missing from the Dependabot page?

Your routine bumps now arrive once a month, grouped, across two ecosystems. Next up, you'll head to the Security tab and prove that security fixes still come through on their own fast track.

Confirm Security Updates Still Arrive Fast

Both ecosystems sit on a monthly schedule now, and the Dependabot page shows exactly when each one next runs. The routine noise is handled.

A monthly cadence raises an obvious worry. If a critical vulnerability lands in one of your pinned packages on the 3rd, does the fix really sit there until next month?

Version updates and security updates run on two separate tracks inside GitHub. This step gets you to prove that for yourself instead of taking it on trust.

In this step, get ready to:

Switch on Dependabot security updates for your repository.
Read the alerts raised against the old versions you pinned.
Prove a security pull request opens straight away instead of queueing behind the monthly run.

Switch on dependabot security updates

Return to your repository on GitHub.com.
Click Settings under your repository name.
In the Security and quality section of the sidebar, click Advanced Security.
Under Dependabot, click Enable to the right of Dependabot security updates.

Why this is a separate switch

The .github/dependabot.yml file you have been editing only configures version updates. Those are the routine bumps you just slowed to monthly.

Security updates are a different feature with its own switch. They react to published advisories rather than to a calendar.

The button to the right of Dependabot security updates now reads Disable. That is your confirmation the feature is live.

Button greyed out?

On public repositories the button is disabled when the feature is always enabled, so your repo already has security updates running. Nothing to fix.

Landed somewhere that looks nothing like this? Help me find the Dependabot settings.

Read your Dependabot alerts in the Security tab

Before you open the page, take a guess. Of the five old versions you pinned, how many do you think have a published vulnerability against them?

Click the Security and quality tab under your repository name.
In the Findings section of the sidebar, select the Dependabot dropdown menu.
Click Vulnerabilities.
Record the package named in the top alert: your alerted package.

The Open tab lists one alert for each pinned version with a published advisory against it. Every one of these was found by a scan that never looked at your schedule.

Watch the security pull request arrive on its own

Click the alert for your alerted package to open its details page.

Make your call before you click anything else. Does the fix for this alert open as a pull request right now, or does it queue up behind the monthly run showing on your Dependabot page?

Click Create Dependabot security update at the top of the alert details page.

The pull request opens immediately. It bumps only the vulnerable package, and it carries none of your grouping.

No button on the alert page?

Dependabot may have opened the fix already. Look for a link to an existing pull request on the same alert page and follow that instead.

Some advisories have no patched version yet, so no fix can be raised. Pick a different alert from the list and try that one.

Still stuck? Why can't Dependabot raise a security update for this alert?

Click the Pull requests tab.

Two pull requests are open. The grouped npm one from earlier, and this single-package security fix that jumped the monthly queue.

Why the monthly schedule doesn't slow security fixes

The schedule and groups keys govern version updates only. That is why your security fix arrived alone rather than folded into all-npm-dependencies.

Security updates are triggered by an advisory landing in the GitHub Advisory Database. You never touched .github/dependabot.yml in this step, and you did not need to.

You have proved the two tracks are independent. Next up, you'll merge the grouped pull request and watch every routine version bump land in a single commit.

Merge the Grouped Pull Request

You've watched the security alert arrive on its own track, untouched by the monthly cadence you set. The grouped pull request is still sitting there, open and unmerged.

Grouping only pays off when the merge is as tidy as the pull request. One pull request should land as one commit that moves every pinned package at once.

In this step you merge the grouped pull request and read the result on your default branch.

In this step, get ready to:

Review what the grouped pull request actually changes in package.json.
Merge the grouped pull request into your default branch.
Confirm every version bump landed in a single commit.

Review the grouped pull request's file changes

Merging blind defeats the point of grouping. The whole promise is that one review covers five bumps, so read the diff once before you press the button.

Open the **Pull requests** tab of your repository.
Click the grouped pull request opened by dependabot.
Click the **Files changed** tab.

You should see package.json as the only changed file, with a red removed line and a green added line for each of your five pinned packages.

Why one diff beats five

Before grouping, reviewing these bumps meant opening five separate pull requests and five separate diffs of the same file.

Now the entire dependency change set is one screen. That is the difference between a review you actually do and a pile you rubber-stamp.

Merge the pull request

Click the **Conversation** tab to return to the top of the pull request.
Click **Merge pull request** near the bottom of the page.
Click **Confirm merge**.

The pull request header turns purple and reads **Merged**.

No merge button, or the merge is blocked?

If the button is greyed out, the branch may be behind your default branch. Click **Update branch** first, then merge.
If you edited package.json directly on the default branch since the pull request opened, you will see a conflict warning. Close the pull request and run **Check for updates** again to get a fresh one.
Still stuck? Why can't I merge my Dependabot pull request?

Confirm every bump landed in one commit

Before you look, make a prediction. How many commits do you expect on your default branch from this merge, and how many package versions will each one touch?

Click the **Code** tab of your repository.
Click package.json in the file list.
Click **History** in the top right of the file view.
Click the newest commit in the list.

One commit holds every change. lodash, express, axios, moment and react all move off their old pinned versions in the same diff.

What this proves about your config

The pile of one-package pull requests from earlier would have produced five separate commits, five separate reviews and five separate chances to lose track.

Your .github/dependabot.yml turned that into one commit. The file is unchanged by the merge, so it drops into any other repository exactly as it is.

Your repository is now fully up to date and your config is the reusable prize. Next up, decide what to keep and what to tear down.

Secret mission

Group Your Security Fixes Too

Your routine bumps now arrive as one tidy pull request. Security fixes still land one at a time, because the group rule you wrote never applied to them. Add a second group with applies-to: security-updates so urgent fixes arrive bundled as well, then narrow the routine group so major bumps break out on their own.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Everything you built lives on a public GitHub repository, where Dependabot version updates are free, so there are no ongoing costs.

Resources you used:

The public GitHub repository you created for this project.
The .github/dependabot.yml config file with your grouped npm entry and your github-actions entry.
The package.json file with the bumped dependency versions on your default branch.
Dependabot version updates, switched on for the repository.
Any Dependabot pull requests you left open.

Save the config before anything else

Your dependabot.yml is the reusable part of this project. It drops into any repository unchanged.

Copy it somewhere you can find it again before you delete or archive the practice repository.

Keep everything running

No action needed. Choose this if you're still actively building on this repository or want to watch the monthly schedule fire on its own.

Leave the repository public so Dependabot version updates stay free.
Expect a grouped pull request on the monthly cadence you set in dependabot.yml.

Your GitHub account also stays as it is, along with any notification settings you changed while working through the project.

Pause - I'll come back to this later

Stop Dependabot opening new pull requests while keeping every file in place. Choose this if you want the repository intact but quiet.

Open your repository on GitHub.com.
Click the Settings tab.
Select Advanced Security in the left sidebar.
Click Disable next to Dependabot version updates.
Close any Dependabot pull requests still open on the Pull requests tab so the repository stops pinging you.

Your .github/dependabot.yml file stays in the repository. Re-enabling version updates later picks the config straight back up.

Delete - I don't want to use this again

Remove the practice repository entirely. Choose this once you have the screenshots you need for your validations.

Open your .github/dependabot.yml file on GitHub and copy its contents somewhere safe.
Open the Pull requests tab and close every Dependabot pull request still open.
Click the Settings tab on your repository.
Scroll to the Danger Zone at the bottom of the General settings page.
Click Delete this repository.
Type the repository name into the confirmation field to complete the deletion.

Deleting the repository removes package.json, the config file, and every Dependabot pull request in one go.

If you'd rather keep the history without the noise, click Archive this repository in the same Danger Zone. An archived repository is read-only and Dependabot stops opening pull requests against it.

Nice Work!

Nice work. You turned a wall of one-package pull requests into a single grouped Dependabot pull request, and you merged every version bump in one commit.

You've learned how to:

Switch on Dependabot version updates with a .github/dependabot.yml file and watch the npm ecosystem for outdated packages.
Bundle routine version bumps into one pull request using a groups block with a patterns entry.
Slow the routine cadence to a monthly schedule and add a second github-actions ecosystem, while security updates keep arriving on their own track.
Secret Mission: Take on the optional challenge that pushes your Dependabot config further.

Ready to quiz yourself?