Configuring Dependabot with Reusable Workflows

[joshjohanning]

Overview

We can already use Dependabot Version Updates for keeping marketplace actions (in addition to internal/private actions) up to date. However, did you know we can use Dependabot for keeping Reusable Workflows up to date as well?

Authorization Options

If you are referring to reusable workflows that are public, the implementation is easy. More likely though, especially if you're in an organization creating reusable workflows to standardize on CI/CD practices, you are going to be working with non-public repositories containing your reusable workflows.

There are two ways that you can configure Dependabot when working with resources in internal or private repositories. To summarize, you can either:

1. Grant access via the UI
   • 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. Create a Dependabot secret
   • 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 accessed 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

Tip

• 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 approach scales better.

Configurations

Approach 1: Grant Access to Dependabot in the UI

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.

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):

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:

Approach 2: Using a Dependabot Secret

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):

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.MY_DEPENDABOT_SECRET }} # the dependabot secret you created

Note

You can create a Dependabot secret at the organization level or repository level.

Results

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

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

Tip

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! 🎉

[madhurigopal]

Check my repo on Real-Time Data Analytics. I think the issue we are facing here is the absence of a Versioning manager which Github already does. So,we may need to fine tune our SQL on our local and try using Dashboards to implement this as a feature or enhancement.