Post

Configuring Dependabot for Reusable Workflows in GitHub

Configuring Dependabot to keep Reusable Workflows up to date in GitHub

Overview

We already can use Dependabot Version Updates for keeping marketplace actions (in addition to custom internal/private actions) up to date (see my post) for more details). However, as of March 2023, we can use Dependabot for keeping Reusable Workflows up to date as well.

Configuration

Authorization

My previous post discusses how there are two ways that you can configure Dependabot when working with resources in internal or private repositories. To summarize, you can either:

  1. When Dependabot can’t access a private repository, the logs allow you to grant authorization to Dependabot to access your repository
    • Alternatively, add it in the organization settings –> Code security and analysis –> Grant Dependabot access to private repositories
    • This setting requires organization admin permissions to access
    • Unfortunately, there isn’t an API to automate this process, it has to be done within the UI
  2. If you plan to create a large number repositories that you want to be a source for Dependabot, creating a Dependabot secret (preferably as an org-level Dependabot secret) with the value of a personal access token (preferably a fine-grained token) that has read-access to the required repositories would be preferred
    • I don’t find it as detrimental to use a personal access token as a Dependabot secret since Dependabot secrets can only be access by Dependabot; you can’t use a GitHub Actions workflow to expose the secret accidentally/intentionally
    • The only concern would be updating the token if it expires, is revoked, or the original author doesn’t have access to the repo(s) anymore

If you only have a few, and rarely increasing set of repositories for custom actions / reusable workflows, I recommend the first approach. If you have a large number of repositories and/or are creating many new repositories for actions / reusable workflows, the second option scales better.

YML

For the first approach (authorizing Dependabot access manually), the YML configuration is no different than if you were using Dependabot to keep marketplace actions up to date.

1
2
3
4
5
6
7
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/" # Workflow files stored in the default location of `.github/workflows`
    schedule:
      interval: "daily"
    open-pull-requests-limit: 5

You will then have to check your Dependabot run logs to authorize Dependabot for that repository (or add it via the organization settings): Noticing a Dependabot run failure A Dependabot failure since it is unable to access private/internal repositories by default

Granting Dependabot access via the Dependabot logs Granting access to Dependabot for this repository

Once you grant Dependabot access to the repository, you will see it show up in organization settings –> Code security and analysis –> Grant Dependabot access to private repositories. Additional repositories can be added here: The repository now shows up under the organization --> Code security and analysis settings --> Grant Dependabot access to private repositories This repository now shows up under organization settings –> Code security and analysis –> Grant Dependabot access to private repositories

For the second option (using a Dependabot secret), you will need to add the registries property to the YML configuration. The registries will reference type: git and use a Dependabot Secret (preferably an org-level Dependabot secret):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: 2
updates:

  - package-ecosystem: "github-actions"
    directory: "/" # Workflow files stored in the default location of `.github/workflows`
    schedule:
      interval: "daily"
    registries:
      - github
registries:
  github:
    type: git
    url: https://github.com
    username: x-access-token # username doesn't matter
    password: ${{ secrets.GHEC_TOKEN }} # dependabot secret

Results

If things are working properly, you should see a successful run in your Dependabot run logs:

Example using Checks to create a line annotation Dependabot is able to access our repositories

And if there is a new semver version of a reusable workflow, you should see a Dependabot-created pull request:

Example using Checks to create a line annotation Example of a pull request for reusable workflow created by Dependabot

Pro-tip: You can reply @dependabot merge or @dependabot squash and merge (among other commands) to tell Dependabot to merge the pull request.

Summary

Now we can create and properly version reusable workflows AND have our downstream users automatically be notified of version updates. This helps a ton in making it front and center for developers that there’s an update they need to look at! 🎉

This post is licensed under CC BY 4.0 by the author.