Home / Enterprise software / Automation

Dependabot Updates hit GA in GHES

Dependabot is generally available in GitHub Enterprise Server 3.5. Here is how to set up Dependabot on your instance.

·@exvuma
| 5 minutes

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.

How to enable Dependabot on your GitHub Enterprise Server instance

As a quick refresher, Dependabot consists of three services:

  • Dependabot alerts: alerts you the moment vulnerabilities in your dependencies are detected
  • Dependabot security updates: upgrades a dependency to the next non-vulnerable version when an exposure is detected by opening a pull request to your repository
  • Dependabot version updates: opens pull requests to keep all your dependencies up to date, decreasing your exposure to vulnerabilities and your likelihood of getting stuck on an outdated version

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:

Prerequisites

To enable Dependabot to update your dependencies:

  • Have an instance of GitHub Enterprise Server running 3.5 or higher.
    • Note: Though Dependabot updates are available on 3.3 and 3.4, 3.5 is the lowest recommended version for general availability support.
  • Enable GitHub Actions on your GitHub Enterprise Server.
    • Note: GitHub Actions is not supported on cluster configurations at this time, so Dependabot is not supported on clustered environments.
  • Set up one or more Linux virtual machines for the self-hosted Actions runners. These runners will be responsible for running the logic behind Dependabot.
  • Set up and configure self-hosted Actions runners with the `dependabot` label.
    • Note: Customers on air-gapped setups are restricted, since the runners for Dependabot updates require internet access.

Setting up GitHub Actions runners

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:

"

Enable Dependabot

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.

  • Enable the dependency graph.
  • Enable Dependabot updates.

"

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:

  • Enable GitHub Connect for your GHES.
  • Make sure both Dependabot settings are enabled.

"

For more information, see “Managing GitHub Connect.”

Test Dependabot updates on a repository

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


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.

How Dependabot on GHES differs from GitHub.com

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.

Learn more about Dependabot and GHES

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.

Tags:

Written by

Related posts