Github Actions for Dependabot PRs

Published on .

#automation #CI #devflow #github #github actions #tech

In this post I want to explore and walk through options we have to get Dependabot PRs checked and verified with GitHub actions.

Context

Setting up GitHub Dependabot for the repository was one of the best workflow decisions I ever made. Return on the modest investment of setting it up is huge. I don’t have to worry about updating dependencies ever again. Unless, of course, it is a major version update requiring application code changes.

Setting up GitHub actions for Dependabot PRs was quite a chore until github allowed elevated permissions for the github token and introduced Dependabot secrets working just like Action secrets.

Previously we would have to use pull_request_target event workflow as a workaround for the security sandbox in which all Dependabot PR actions run. We had to maintain a modified copy of the regular pull_request workflow and use some discouraged workarounds to gain access to the github token and action secrets. Fortunately now that is a thing of the past.

Today we can use our regular pull_request event workflow with additional jobs specific for Dependabot PRs. Another thing you need to do is to copy relevant secrets from action secrets to dependabot secrets.

Additional jobs

For instance I wanted to add Ready to merge label for every Dependabot PR passing CI checks. This allows me to merge them wo looking into code changes or checking the long list of checks passed. Yes, there is also an auto-merge option for the brave.

CI checks are performed by the original pull_request event workflow and we can simply add another job to the end of the queue:

add_label:
  name: Add label
  runs-on: ubuntu-latest

  # use your last CI check step here
  needs: e2e-test

  # sender.login is needed for runs re-triggered from GitHub UI
  if: github.actor == 'dependabot[bot]' || github.event.sender.login == 'dependabot[bot]'

  steps:
    - uses: actions-ecosystem/action-add-labels@v1.1.0
      name: Add label
      with:
        github_token: ${{ github.token }}
        number: ${{ github.event.number }}
        labels: ready to merge

yaml

Since open PR can be rebased or otherwise updated we better add one more job to remove potentially stale Ready to merge label before running other jobs.

# have this job run early in the workflow
remove_label:
  name: Remove label
  runs-on: ubuntu-latest

  if: |
    (github.actor == 'dependabot[bot]' || github.event.sender.login == 'dependabot[bot]') &&
    contains(github.event.pull_request.labels.*.name, 'ready to merge')

  steps:
    - uses: actions-ecosystem/action-remove-labels@v1.1.1
      name: Remove label
      with:
        github_token: ${{ github.token }}
        number: ${{ github.event.number }}
        labels: ready to merge

yaml

Additional workflow_run workflows

Alternatively we can add two more separate workflows, triggered via workflow_run of the original pull_request workflow.

name: Dependabot PR - Before & After

on:
  workflow_dispatch:
  workflow_run:
    # "PR Update" is name of the main CI checks workflow
    workflows: ["PR Update"]
    types:
      - requested
      - completed

yaml

This allows us to keep CI checks logic separate from Dependabot specific stuff but does make the setup a little more verbose and complicated.

Dependabot PR After workflow will get triggered on the regular pull_request workflow completion.

It performs two checks — if the the pull_request workflow was triggered by the Dependabot PR and if it had completed successfully. When both conditions are met it adds Ready to merge label to the Dependabot PR.

Dependabot PR Before runs before the main pull_request workflow and removes potentially stale Ready to merge label from the PR.

Here you can check the code of before and after workflows I’m using.

Conclusion

Setting up CI checks for Dependabot PRs have never been easier. Nowadays we have two options: additional jobs for the main workflow or separate workflows running on workflow_run event.

Fist one is very straightforward while second one allows to have better separation of concerns.

References