Automated dependabot configuration in GitHub

Heyko Oelrichs
4 min readJan 7, 2022

Some of you might be already familiar with dependabot, a neat solution to monitor your GitHub repository to ensure that your solution automatically keeps up with the latest releases of the packages and applications it depends on.

Dependabot is integrated in GitHub and supports a wide variety of packages called “ecosystems” including Docker, Terraform, NPM, Maven, NuGet and others. See Supported repositories and ecosystems for a complete list.

You can enable dependabot by creating a dependabot.yml file in your GitHub repository that contains specific configuration blocks for each of the components used. Here is an example for NPM:

Example dependabot.yml that contains a configuration block for npm

Dependabot then determines if there is a newer version of a dependency and creates, if possible, a pull request for each identified outdated dependency.

Here is an example how such a PR looks like for a new release of the AzureRM Terraform provider:

Pull request created by dependabot for a Terraform provider update

This works great and is super helpful to maintain your dependencies, but the configuration is static. New components in new directories like for example a new Dockerfile, a new Terraform definition or for example a renamed or moved directory can cause dependabot to lose sight of a component. This often times happens unnoticed.

To avoid that and further automate the use of dependabot, I have written a small PowerShell script to browse through your repository and auto-generate a dependabot.yml file.

Note! Please treat this script only as an example, it does not support all the supported package ecosystems, yet and serves only as a proof of concept.

Calling the update-dependabot.ps1 with the parameter outputFile set it will write its outputs directly into a YAML file. For example directly into .github/dependabot.yml. Calling it without the outputFile parameter set will print out the results.

Output of update-dependabot.ps1 showing the list of identified components

As you can see in the screenshot above the output is written directly into the .github/dependabot.yml file.

# This file is auto-generated by .github/scripts/update-dependabot.ps1
version: 2
- package-ecosystem: "nuget"
directory: "/src/app"
interval: "daily"
target-branch: "component-updates"
- package-ecosystem: "docker"
directory: "/src/app/AlwaysOn.GameService"
interval: "daily"
target-branch: "component-updates"
- package-ecosystem: "docker"
directory: "/src/app/AlwaysOn.HealthService"
interval: "daily"
target-branch: "component-updates"

As it is still a manual activity to run the update-dependabot.ps1 we can further automate it by using GitHub Actions to run this script everytime a new commit or a pull request was made to a given repo or branch.

This workload executes the update-dependabot.ps1 and auto-generates and overwrites the existing .github/dependabot.yml configuration file.

To make troubleshooting and debugging easier are we writing every identified file to STDOUT:

UpdateDependabot GitHub Actions workflow output

Identified changes, in our case to the dependabot.yml, are automatically added to the same PR.

Changes are automatically added to the PR
“Files changed” section of PR that contains changes to our dependabot.yml

After you have successfully enabled and configured dependabot, you can see the components monitored, their status and some logs in your GitHub repository under Insights > Dependency graph > Dependabot:

Dependabot in a GitHub repository

The update-dependabot.ps1 PowerShell script shared above is definitely not complete and can be further improved and optimized, but it is a good starting point how to auto-generate the dependabot configuration for your repository.

Things you should keep in mind are that you might not want to monitor everything and that you could lose some flexibility in configuring the different components differently. Also are my filters for example using to identify Terraform, or packages.json to identify NPM not perfect. This could be improved by checking the contents of these files for certain patterns like for example a terraform {} block to make sure that it’s Terraform and so on.