Dependabot is generally available in GitHub Enterprise Server 3.5. Here is how to set up Dependabot on your instance.
Dependabot updates are now generally available in GitHub Enterprise Server 3.5 🎉! Dependabot alerts have been available on GitHub Enterprise Server (GHES) for years, but support for Dependabot updates––the ability to update dependencies automatically by opening pull requests––have been a long-standing feature request from GHES customers.
As a quick refresher, Dependabot consists of three services:
In this post, we’ll walk through the steps for enabling Dependabot on your enterprise server, and more detailed reference material can be found in GitHub Docs:
To enable Dependabot to update your dependencies:
To configure a GitHub Actions runner, follow the steps outlined in our documentation. GitHub Enterprise Server will provide you with a set of commands to run on your virtual machine that add self-hosted runners to the runner pool.
When configuring a runner for Dependabot, you must configure your runners with the dependabot label to indicate that this runner is available for Dependabot update jobs. You’ll be prompted to add a label and a group. After running ./config.sh in your terminal you’ll see the following:
Optionally, you can use a runner group to manage your Dependabot runners. If using repository or organization-level runner groups, make sure each runner is part of the Dependabot runner group and the repositories have access to this group you should have a runner group. Here is what your group would look like:
In the site admin Management Console under Security, enable the following features. Please note that enabling Dependabot on your server requires a brief downtime where your server will be restarted.
For more information, and for step-by-step instructions, see: Enabling Dependabot for your enterprise and Enabling the dependency graph for your enterprise in the docs.
Navigate to GHES settings, then GitHub Connect:
For more information, see “Managing GitHub Connect.”
Navigate to a test repository, and go to Settings, then Security and Analysis. Enable Dependabot security updates. You may also configure Dependabot security updates at the organization level by following the same pattern.
If you would like to enable Dependabot version updates, you will need to add a configuration file to each repository you want kept up-to-date.
You can test that Dependabot security updates are working properly by introducing a known bad dependency, for example, by adding a requirements.txt file with the following content.
requirements.txt file
Victoria Fawcett
pillow>= 2.4.0, < 5.3.1
Committing this file will trigger your repository to receive both Dependabot alerts and Dependabot security updates.
See Configuring Dependabot version updates – GitHub Docs and About Dependabot security updates – GitHub Docs.
Dependabot creates pull requests by analyzing the available versions of your dependencies and calculating the lowest secure version that you should run. On GitHub.com, Dependabot runs this analysis using internal infrastructure developed before GitHub Actions was a product. With GHES appliances, we needed to find a way to process these containers so they would not impact the availability of your GitHub Enterprise Server instance, would play nice with a variety of GHES instances, and also would plug into a repo’s CI. This is where Actions come in. The images running to create update pull requests are packaged using GitHub Actions. Find out how this rearchitect came to life here.
Having Dependabot updates run in GitHub Actions means you get the niceties that come with Actions. For example, you can watch Dependabot create pull requests and monitor the logs just like you would with other actions!
Please note that you cannot currently rerun jobs as you would with other Actions. Also, Dependabot on GHES only works with self-hosted runners.
Here are some of the links used in this post to walk you through more detailed steps of enabling Dependabot on your Enterprise instance:
We hope you are as excited about Dependabot on GHES as we are! We are eager to hear what you think about the experience, and welcome comments or questions in the feedback discussion.
Start your free trial for 30 days and increase your team’s collaboration. $21 per user/month after trial expires.
Curious about other plans?
In March, we experienced two incidents that resulted in degraded performance across GitHub services.
In February, we experienced two incidents that resulted in degraded performance across GitHub services.
With this version, customers can choose how to best scale their security strategy, gain more control over deployments, and so much more.
