Dependabot: GitHub, and Terraform versions management

Over time, as the project grows, sooner or later the question of upgrading versions of packages, modules, and charts will arise.

You can do it manually, of course, but only up to a certain point, because eventually you simply won’t be able to physically monitor and update everything.

There are many solutions for automating such processes, but the most commonly used are Renovate and Dependabot.

According to the results of the UkrOps Slack poll, Renovate got a lot more votes, and indeed, it can do more than Dependabot.

On the other hand, Dependabot is already available in GitHub repositories, available in all pricing plans, so if you use GitHub, you just need to add a configuration file to set up Dependabot. Although, looking ahead, Renovate is even easier to set up, but more on that in the next post — Renovate: GitHub, and Helm Charts version management.

Actually, you can have Dependabot on almost all platforms — GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket, and AWS CodeCommit, see How to run Dependabot.

But — and this was a big surprise for me — Dependabot can’t work with Helm charts. It works with Terraform, though, and is already available in some of our Python code repositories, so let’s take a look at it first.

Again, looking ahead, I liked Renovate a lot more, and we will be using it.

How Dependabot is working

Here’s how it works:

• create a Dependabot configuration file in a repository
• in the file, describe what exactly it should check — pip libraries, Terraform modules, etc.
• describe what exactly is of interest — security updates or versions updates
• when updates are found — Dependabot creates a Pull Request, in which it adds details on the update
• …
• Profit!

So what are we going to do today?

• we have a GitHub repository for monitoring
• we have Terraform code there
• and will configure versions checks and PR creation with Dependabot

Documentation — Dependabot Quick Start Guide, Configuration options for the dependabot.yml file.

See also Supported Repositories and Ecosystems — what systems Dependabot supports.

Dependabot and Terraform

What we can monitor with Dependabot in the context of Terraform is the versions of providers and modules.

For example, we have two files  —  versions.tf, where the versions of the providers are set, and a lambda.tf, where we use several modules - terraform-aws-modules/security-group/aws, terraform-aws-modules/lambda/aws, and others:

Now, for Dependabot to start monitoring versions in them, we create a directory .github, and in it a dependabot.yml file:

Set the parameters in the file:

version: 2
updates:
  - package-ecosystem: "terraform"
    directory: "/terraform"
    schedule:
      interval: "daily"
      time: "09:00"
      timezone: "Europe/Kyiv"
    assignees:
    - arseny-zinchenko
    reviewers:
    - arseny-zinchenko
    open-pull-requests-limit: 10

In general, everything is clear from the names of the parameters:

• package-ecosystem: since this configuration is for Terraform, we specify it
• directory: Terraform files are in the terraform directory in the root of the repository
• schedule: the schedule of checks - at the same time, when you first add the file dependabot.yml, it will start the check immediately, and it is possible to run it manually later
• assignees and reviewers: immediately create a PR for me
• open-pull-requests-limit: by default, Dependabot opens a maximum of 5 PRs, you can increase it with this parameter

Push it to the repository and check the status.

In the repository, go to Insights > Dependency graph > Dependabot, and see that the check has started:

In a minute, we’ll have open Pull Requests:

At the same time, Dependabot adds some details about the update in the comments — Release notes, Changelog, etc:

However, for some reason, not everywhere.

For example, an update for the Lambda module was created without details:

But Renovate does it much better.

Dependabot, and GitHub Secrets

Another nuance is the GitHub Secrets that are available to Dependabot.

When we have a PR with changes in the terraform directory in our repository, we run a GitHub Actions Workflow that performs checks from Terraform (see GitHub Actions: Terraform deployments with a review of planned changes).

This workflow is located in a dedicated repository, and to access it, a GitHub Deploy Key is passed to the calling workflow via GitHub Actions Secrets.

But in the GitHub Actions job launched by Dependabot, this step failed:

Although the workflow itself passes all secrets through the secrets: inherit:

...
jobs:
  terraform-test:
    # call the Reusable Workflow file
    uses: ORG_NAME/atlas-github-actions/.github/workflows/call-terraform-check-and-plan.yml@master
    with:
      aws-iam-role: ${{ vars.AWS_IAM_ROLE }}
      aws-env: ${{ vars.AWS_ENV }}
      pr-num: ${{ github.event.pull_request.number }}
      environment: ops
      slack-channel: '#cicd-devops'      
    secrets:
      inherit

However, for Dependabot, these secrets must be set separately — not in Actions secrets and variables > Actions, but in the Actions secrets and variables > Dependabot:

Add a new secret to it, and now the check works:

Dependabot, and private registries/repositories

Among other things, we have our own Terraform modules stored in a private repository.

When accessing them, Dependabot will fail the check with the error “ Dependabot can’t access ORG_NAME/atlas-tf-modules ”:

The first option is to add this repository or another registry explicitly in the dependabot.yml file - see Configuring private registries.

The second option is to simply click Grant access, which will open access to the repository for all repositories in the organization.

Or do it manually — go to Organization settings > Security code > Global settings, and in Grant Dependabot access to private repositories add access to the desired repository:

Dependabot, and manual run

Now that you have added access, go back to the repository, go to Insights > Dependency graph > Dependabot, click Check for updates:

And the check is running:

In general, that’s all. Now we will have updates for Terraform without having to subscribe to all the repositories ourselves.

Although, once again, Renovate is really better. See Renovate: GitHub, and Helm Charts version management.

Originally published at RTFM: Linux, DevOps, and system administration.