In this era of microservice architectures, something as mundane as updating dependencies can become daunting. Dependabot has become the de facto solution to identifying dependencies that have updates. However, many approaches to keeping dependencies up to date are still semi-automated; Dependabot is used to create a PR for the update of a dependency and leaving the merging of the PR to a human being.

With GitHub Actions, one can define a workflow that completely automates the merging of Dependabot PRs. Below is a summary of the setup I have configured to automate merging Dependabot PRs with minimal toil using GitHub Actions.

• Allow GitHub auto-merge.

• Add branch protection rules to require a status check to pass before merging.

• Enable Dependabot version updates on your repository.

• Add a GitHub Actions workflow to approve and auto-merge Dependabot PRs. This workflow will work as follows:

  • Workflow is triggered on pull_request_target which means it runs when a PR is opened, updated, or reopened.

  • If the PR was created by the dependabot[bot] entity/actor then the pipeline runs. Otherwise, it skips.

  • To only allow auto-merging of minor and patch-level updates, add a condition that checks that the Dependabot metadata is not for a major version update.

  • If only merging none major versions, add a condition to only approve PR when the version is not a major update. Otherwise, all Dependabot PRs including major version updates will be approved and this can lead to some confusion.

The above approach is inspired by Jeff Yate's article, read it for more details that I have left out, especially the important security considerations. Below is my final implementation.

name: Dependabot PR Auto Approve & Merge

on: pull_request_target

permissions:
  pull-requests: write
  contents: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    # Checking the actor will prevent your Action run failing on non-Dependabot
    # PRs but also ensures that it only does work for Dependabot PRs.
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      # This first step will fail if there's no metadata and so the approval
      # will not occur.
      - name: Dependabot metadata
        id: dependabot-metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
      # Here the PR gets approved.
      - name: Approve a PR
        if: ${{ steps.dependabot-metadata.outputs.update-type != 'version-update:semver-major' }}
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      # Finally, this sets the PR to allow auto-merging for patch and minor
      # updates if all checks pass
      - name: Enable auto-merge for Dependabot PRs
        if: ${{ steps.dependabot-metadata.outputs.update-type != 'version-update:semver-major' }}
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Notes:

• Changing GITHUB_TOKEN permissions - by default, GitHub Actions workflows triggered by Dependabot get a GITHUB_TOKEN with read-only permissions. You can use the permissions key in your workflow to increase access for the token. This is relevant for the workflows that are triggered when the Dependabot PR for the dependency update is running and includes steps like publishing test results or Terraform results that will need more than read-only access to GitHub resources. Apply the permissions directly on the specific jobs that need the extra permissions.

• Review code owner approvals rule - if your branch protection rules require for PRs to be approved by code owners, you might need to review how this will work to allow Dependabot approvals to be the only approval needed in the automated workflow.

• Interactions with Dependabot PRs - for the above workflow to be triggered, the PR interactions need to have been initiated by @dependabot. For example, instead of manually rebasing a PR by checking out the branch on your local machine or opting to use the "update PR" option in GitHub, use the @dependabot rebase command action so that the action actor remains dependabot[bot] allowing the auto-merge workflow to be triggered.

• Consider sending a notification to the team at the end of each run.

  • On successful automatic merge, it is useful for the team to be notified that an update was done on their behalf so that they are aware and start taking advantage of the newly introduced updates. Remember these could be fixes to bugs that were affecting the team, or security vulnerabilities addressed. At the end of the day, the team will be better off knowing the current state of their dependencies.

  • On failed automatic merge, the team will need to manually intervene and fix the issue that's caused the PR automatic merge to fail.

• How to handle major version updates? If the status check has passed, what's stopping us from automatically merging a major version update? For now, I believe there is value in being deliberate and conscious of when and how to adopt major version updates. For each major version update, the team will find it beneficial to be informed on what the update entails and how that is going to affect how they use the just updated dependency.

I hope the above approach has summarized an approach that can help teams automate the toil of dependency management, allowing teams to focus on more pressing domain problems.

Resources:

• https://blog.somewhatabstract.com/2021/10/11/setting-up-dependabot-with-github-actions-to-approve-and-merge/

• https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions

• https://github.com/features/actions

• https://github.com/dependabot