Streamline dependency updates with Mergify and Snyk

SnykSec - Aug 24 '23 - - Dev Community

Managing dependencies for a project is a task that requires consistent effort and attention. Surely, you’ve found yourself concerned about any of the following while maintaining a project:

  • A dependency has new versions released for a feature or a bug fix.
  • A dependency has security vulnerabilities and releases fixes in newer versions.
  • Staying up to date with dependency versions to avoid stale and outdated code.

Luckily, we’ve been able to use GitHub bots to automate dependency management to an extent with solutions like Dependabot and GreenKeeper.

However, these bots mostly automate the creation of a new code pull request that proposes the changes to be made. Merging each one is still a manual process that requires a close eye to avoid merging a pull request that breaks the CI.

What’s better than automating dependency updates? Automated merging.

What is Mergify?

Mergify is a powerful, innovative tool designed to automate your GitHub workflows, allowing you to focus more on crafting excellent software and less on fiddly administration tasks. At its core, Mergify is a pull request automation service that helps you create custom workflows based on specific conditions you define. This could include automatically merging, closing, commenting, reviewing, labeling, forwarding, back-porting, rebasing pull requests, and a lot more.

After set up, Mergify takes over some of the more tedious parts of code review and project management. It helps maintain your repo’s hygiene, ensures your master branch remains green, and minimizes time wasted having to manually handle processes that could be automated.

In the next section, we'll reveal how you can harness the power of Mergify to make your dependency updates less of a nightmare and more of a dream.

About Snyk dependency upgrade PRs

Staying up to date with vulnerability fixes and stale dependencies? This is where Snyk comes in.

Snyk is a developer-friendly security platform that empowers developers to own the security of their applications. Although Snyk is renowned for its vulnerability scanning capabilities, it also offers a seamless experience in managing dependency updates, specifically via its automated pull requests.

So, how do Snyk's dependency upgrade PRs work? At a regular frequency, Snyk automatically checks all your project dependencies for any available updates. When it identifies a newer version, it creates a pull request with the necessary changes for the update directly on your GitHub repository. This pull request includes comprehensive information about the upgrade, such as the dependency drift timeline and the last version release date, providing a thorough review before you merge the changes.

Getting started

You’ll need to complete a few simple steps to get started:

  1. Choose one of your GitHub code repositories to install the automated dependency upgrade and merge workflow.
  2. Create a Mergify account and invite the Merigy GitHub App to your repository.
  3. Create a Snyk account and connect your GitHub repository to it.

Enable automatic dependency upgrade with Snyk

Open the Snyk app, continue with sign-up if necessary, and connect the repository you want to automate by importing a GitHub repository. Go to the Projects page in the Snyk UI, select Add projects, select the code repositories to import to Snyk, and click*Add selected repositories*.


After the project imports successfully, enable dependency upgrade PRs with Snyk by selecting Settings, then Integrations, and GitHub:


Then, scroll down to locate the Automatic dependency upgrade PRs configuration section and turn the feature on:


Now that we have the Snyk bot automatically opening upgrade pull requests for project dependencies, we’ll visit Mergify configuration to automate merging the pull request.

Create a Mergify auto-merge policy

Connect to Mergify with your GitHub account, similarly to how you did with Snyk, and next up, we’re going to add repositories to manage with Mergify.

To edit the git repositories that you want to manage with Mergify, you’ll be redirected to the GitHub applications page and be able to choose each of them from the dropdown:


When you’re done selecting repositories to add Mergify to, click the Save button.

Next, we need to configure the merge policy for our project. We set the merge configuration using .mergify.yml file in the root of the repository. Tip: you can also place the file in the .github/ directory to co-locate it with other CI-related workflows and configurations.

Mergify’s YAML configuration file consists of the following building blocks:

  • Merge queues - A queue in which PRs are pushed as items that await to be merged, one by one to your main branch without introducing merge conflicts or breaking changes.
  • Pull request rules - As the name implies, a set of conditions to validate pull requests and then take actions, such as moving them to a merge queue.

Here’s a simple example:

pull_request_rules:
  - name: automatic merge on approval
    conditions:
      - "#approved-reviews-by>=1"
    actions:
      merge:
        method: merge
Enter fullscreen mode Exit fullscreen mode

The above configuration will merge the pull request if the condition is met whereby at least one reviewer approves the pull request. 

Without Mergify, a reviewer might have approved the change introduced by the pull request very quickly, but they’d have to wait for all the CI checks to pass — or until the person who created the pull request acknowledged their approved review is ready to merge. Merging is a manual action.

With the above conditions and Mergify, upon an approved review, the pull request will automatically merge into the main branch.

Automatically merge Snyk upgrade pull requests

Let’s add the same automation to the Snyk pull requests that upgrade dependencies. The contents of our Mergify configuration will look like the following:

queue_rules:
  - name: Snyk PRs Queue
    conditions:
      - "check-success ~= .*"

pull_request_rules:
  - name: Automatic merge Snyk PRs on Status Checks passing
    conditions:
      - title~=^\[Snyk\]
      - head~=^snyk-fix
      - base=main
    actions:
      queue:
        name: "Snyk PRs Queue"
      label:
        add:
          - "auto-merge"
Enter fullscreen mode Exit fullscreen mode

Let’s break this down to explain what is happening here:

  • A new merge queue is created with the name of Snyk PRs Queue in which pull requests will be merged only if and when they confirm the condition where all CI status checks are passed. This ensures that our tests and other automations that run in CI complete successfully and the upgraded dependency versions do not introduce a breaking change (as far as our tests can tell).
  • To push pull requests into the Snyk PRs Queue they will need to match the following conditions:

    • The pull request title starts with [Snyk].
    • The head branch name of the pull request starts with snyk-fix.
    • The base branch name (which we merge the pull request to) is main.

If the above conditions are met, we label the pull request with the “auto-merge” GitHub label and push it to the Snyk PRs Queue.

Let’s commit the new Mergify configuration file to the repository and watch the magic happen when Snyk introduces a new pull request:

Tip: Use Snyk dependency upgrade policies to reduce the noise

Automating dependency pull requests could quickly overwhelm your team with the sheer volume of pull requests. Achieving a balance where updates do not obstruct your team's workflow is crucial. This is where Snyk's dependency upgrade policies come in handy.

  1. Limit the number of simultaneous upgrade PRs open: Snyk allows you to manage the volume of pull requests by limiting how many automated upgrade PRs can be open at a time. This ensures that your team doesn't drown in a sea of upgrade requests and can focus more on critical development tasks in their pipeline.

  2. Choose which packages you wish to ignore upgrading: Not all packages require or warrant frequent updates. Sometimes, relentlessly upgrading to the latest version may break your code or leave it unstable. For such scenarios, Snyk allows you to ignore specific packages from its automated updates. Therefore, you have control over your dependency update schedule, focusing only on the packages that matter most to your project.

  3. Limit the scope of changes by upgrading minor and patch versions only: Dealing with major version upgrades can sometimes be more trouble than it's worth, often requiring additional code changes due to breaking changes. With Snyk, you can choose to automatically upgrade minor and patch versions only. This retains the stability of your application while still taking advantage of non-breaking improvements and security patches.

Implementing these three policies will help reduce the noise from dependency upgrades, making it easier for your developer team to keep track of essential updates and preventing the chances of codebase chaos. Remember, the goal of automated updates is to relieve the burden of manual updates — not to shift it elsewhere. Leverage Snyk's powerful features to maintain a smooth, well-ordered CI workflow free from unnecessary distractions.

Automate and forget

Merging automatically dependency upgrades can help increase your team’s velocity and productivity, and it’s a great automation opportunity.

With Snyk's dependency upgrade PRs, you no longer need to manually track and check for dependency updates. Say goodbye to overwhelming dependency updates and embrace a more streamlined, secure, and straightforward update process. Mergify and Snyk, when used together, can take your workflow to the next level.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .