fossabot for Dependency Upgrades

fossabot is an AI Agent for making strategic dependency updates and is capable of large complexity upgrades – the ones that require a senior engineer because they’re always an unexpected multi-hour research and coding task.

Using fossabot with Dependabot, Renovate or Snyk

fossabot works with existing dependency update tools you might already have: Dependabot, Renovate and Snyk. When Pull Requests from these tools are detected, fossabot can automatically analyze the proposed upgrade for breaking changes and determine if your application is impacted by the changes.

Using fossabot to Propose Upgrades

fossabot can propose its own intelligent updates, which allows you to easily catch up on your dependency upgrade backlog. By default, these Pull Requests will group together a set of dependencies that should be upgraded together, without any configuration required.

Configuration can be specified to control the number of automatically opened upgrades, the cooldown period, and how vulnerability remediation should skip the line. Each code repository can have multiple of these files, which is common in a mono-repo.

# yaml-language-server: $schema=https://api.fossabot.fossa.com/schemas/fossabot-config.v1.json
version: 1

defaults:
  maxOpenPRs: 3
  minimumReleaseAge: 7
  securityCvssThreshold: 7.0

A more detailed breakdown for how the "best" upgrades are selected is documented below.

Using fossabot to Fix Breaking Changes

When fossabot discovers issues in your code, caused by breaking changes, a fix can be attempted with @fossabot fix (or /fossabot fix on GitLab). Context discovered during the analysis is used to fix as many issues as possible, including using Continuous Integration failures as a guide.

A prompt designed for AI coding tools is also generated, in case you want to fix the issue locally yourself.

How fossabot Selects the "Best" Upgrades to Propose

fossabot executes a multi-step selection process, on a weekly basis, to find the "best" upgrades for your repository to apply. The "best" is subjective based on the current state of your code, but the following are the goals:

• Lower noise by intelligently grouping related dependencies
• Propose both regular maintenance bumps alongside security fixes
• Don't open more Pull Requests than desired (default is 3)
• Score important security updates highly and allow them to skip the max upgrade threshold
• Explore pathways for smaller patch upgrades, as well as minor and major, to find the best risk/reward of new features and performance enhancements versus breaking changes or deprecations.

Scoring Process

The Available Updates list on each of your repositories is a visual representation of the final result.

It's expected to see overlapping groups, such as a patch and minor upgrade of the same package, since this allows for the widest research to occur.

These are the scoring steps:

1. Take an inventory of the out-of-date packages in the repository
2. Recognize sub-projects if the codebase is a monorepo
3. Group dependencies
4. Annotate groups that are related to vulnerable dependencies
5. Fetch and process details about each upgrade from a variety of sources:
   1. Release notes and changelogs
   2. Migration guides and readme content
   3. Commits contained in the release
6. Score positive indicators:
   1. Bug fixes
   2. New features
   3. Performance enhancements
   4. Security improvements
7. Score negative indicators:
   1. Breaking changes
   2. Deprecations
8. Finalize scores and deduplicate overlapping upgrades

Making Pull Requests

After scoring, fossabot needs to do two things:

1. Close out-of-date Pull Requests
2. Post new Pull Requests, based on the configured policy

All of this happens in the background automatically. The result is a huge amount of filtering out bad upgrades and noise, so engineers are left with high quality upgrade proposals.

After the Pull Requests are posted, the detailed app impact analysis will occur, including signals from your test suites and other Continuous Integration gates.