fossabot for Dependency Upgrades
fossabot proposes strategic dependency updates, groups related upgrades, and fixes the breaking changes they introduce.
Overview
fossabot is an AI agent for making strategic dependency updates. It is built for the large, complex upgrades that usually need a senior engineer, the ones that turn into an unexpected multi-hour research and coding task.
Using fossabot with Dependabot, Renovate, or Snyk
fossabot works alongside the dependency tools you already use. When it sees a pull request from Dependabot, Renovate, or Snyk, fossabot analyzes the proposed upgrade for breaking changes and evaluates the impact on your application.
Using fossabot to propose upgrades
fossabot can also propose upgrades on its own, which helps teams work down a dependency backlog. By default it groups related dependencies into a single pull request, with no manual configuration required.
fossabot chooses which upgrades to propose through a weekly scoring process, described in How fossabot selects the best upgrades below.
You can tune this behavior with a configuration file committed to your repository. Monorepos are supported: place multiple configuration files in a single repository.
# yaml-language-server: $schema=https://api.fossabot.fossa.com/schemas/fossabot-config.v1.jsonversion: 1 defaults: maxOpenPRs: 3 minimumReleaseAge: 7 securityCvssThreshold: 7.0| Field | Description |
|---|---|
version | Configuration schema version. Use 1. |
defaults.maxOpenPRs | Maximum number of fossabot pull requests open at once. |
defaults.minimumReleaseAge | Minimum age, in days, before a release is eligible for an upgrade, acting as a cooldown period. |
defaults.securityCvssThreshold | CVSS score at or above which fossabot prioritizes a security upgrade. |
Using fossabot to fix breaking changes
When an upgrade introduces a breaking change, ask fossabot to fix it:
- GitHub: comment
@fossabot fix. - GitLab: comment
/fossabot fix.
fossabot generates a prompt for the fix and attempts the correction automatically, using your CI failure output to guide the change.
How fossabot selects the best upgrades
Once a week, fossabot runs a multi-step selection process to find the best upgrades to propose for each repository. What counts as "best" depends on the current state of your code, but the process optimizes for a few goals:
- Lower noise by grouping related dependencies.
- Propose routine maintenance bumps alongside security fixes.
- Stay within your open pull request limit (
maxOpenPRs, default 3). - Score important security updates highly, and let them skip the open pull request limit.
- Explore patch, minor, and major upgrade paths to balance new features and performance against breaking changes and deprecations.
Scoring process
The Available Updates list on each repository is a visual representation of the final result. Overlapping groups are expected, such as a patch and a minor upgrade of the same package, because this gives fossabot the widest range to research.
fossabot scores upgrades in these steps:
- Take an inventory of the out-of-date packages in the repository.
- Recognize sub-projects, if the repository is a monorepo.
- Group related dependencies.
- Annotate groups that are tied to vulnerable dependencies.
- Fetch and process details about each upgrade from several sources:
- Release notes and changelogs.
- Migration guides and README content.
- The commits contained in the release.
- Score positive indicators: bug fixes, new features, performance enhancements, and security improvements.
- Score negative indicators: breaking changes and deprecations.
- Finalize scores and deduplicate overlapping upgrades.
Making pull requests
After scoring, fossabot does two things:
- Closes out-of-date pull requests.
- Opens new pull requests, following your configured policy.
This happens automatically in the background. The result is that most low-value upgrades and noise are filtered out, leaving engineers with a short list of high-quality proposals. Once the pull requests are open, fossabot runs its detailed application impact analysis, drawing on your test suites and other continuous integration signals.