Dependabot Core

What's Changed

• Rescue errors in metadata_cascades_for_dep to prevent PR message loss by @yeikel in https://github.com/dependabot/dependabot-core/pull/14905
• Bump sigstore from 4.1.0 to 4.1.1 in /npm_and_yarn/helpers by @dependabot[bot] in https://github.com/dependabot/dependabot-core/pull/15484
• Bump handlebars from 4.7.8 to 4.7.9 in /npm_and_yarn/helpers by @dependabot[bot] in https://github.com/dependabot/dependabot-core/pull/14547
• Bump lodash from 4.17.23 to 4.18.1 in /npm_and_yarn/helpers by @dependabot[bot] in https://github.com/dependabot/dependabot-core/pull/14605
• fix: use canonical LOCKFILE_ENTRY_REGEX in replace-lockfile-declaration.ts by @thavaahariharangit with @Copilot in https://github.com/dependabot/dependabot-core/pull/15642
• Prevent update job crash when a pinned GitHub Actions SHA is missing by @robaiken in https://github.com/dependabot/dependabot-core/pull/15628
• feat(npm_and_yarn): enhance downgrade conflict messages with detailed blocking dependencies by @thavaahariharangit in https://github.com/dependabot/dependabot-core/pull/15656
• Cargo: handle crates locked at multiple versions by @p-linnane in https://github.com/dependabot/dependabot-core/pull/15638
• Revert "Cargo: handle crates locked at multiple versions" by @kbukum1 in https://github.com/dependabot/dependabot-core/pull/15667
• Paginate Docker tag listing and classify registry error responses by @robaiken in https://github.com/dependabot/dependabot-core/pull/15651
• fix: Import proxy CA certificate into Java truststore for Java package managers by @thavaahariharangit in https://github.com/dependabot/dependabot-core/pull/15670
• Bump gradle from 4a253a2 to 2a6880c in /gradle by @dependabot[bot] in https://github.com/dependabot/dependabot-core/pull/15620
• Fix security update jobs failing with dependency_file_not_found for single-directory manifests by @thavaahariharangit with @Copilot in https://github.com/dependabot/dependabot-core/pull/15658
• Make Dependency strongly typed by @JamieMagee in https://github.com/dependabot/dependabot-core/pull/15647
• v0.389.0 by @dependabot-core-action-automation[bot] in https://github.com/dependabot/dependabot-core/pull/15691

New Contributors

• @p-linnane made their first contribution in https://github.com/dependabot/dependabot-core/pull/15638

Full Changelog: https://github.com/dependabot/dependabot-core/compare/v0.388.0...v0.389.0

<h1 align="center">

<picture>

<source media="(prefers-color-scheme: light)" srcset="https://user-images.githubusercontent.com/7659/174594540-5e29e523-396a-465b-9a6e-6cab5b15a568.svg">

<source media="(prefers-color-scheme: dark)" srcset="https://user-images.githubusercontent.com/7659/174594559-0b3ddaa7-e75b-4f10-9dee-b51431a9fd4c.svg">

<img src="https://user-images.githubusercontent.com/7659/174594540-5e29e523-396a-465b-9a6e-6cab5b15a568.svg" alt="Dependabot" width="336">

</picture>

</h1>

Welcome to the public home of Dependabot :dependabot:.

Table of Contents

• What is Dependabot-Core?
• How to run Dependabot
• Contributing to Dependabot
• Reporting Issues and Feature Requests
• Submitting Pull Requests
• New Ecosystems
• Development Guide
• Getting a Development Environment Running
• Debugging Problems
• Running Tests
• Profiling
• Architecture and Code Layout
• Trademarks
• Notes for Project Maintainers

---

What is Dependabot-Core?

Dependabot-Core is the library at the heart of Dependabot security / version updates.

Use it to generate automated pull requests updating dependencies for projects written in Ruby, JavaScript, Python,

PHP, Dart, Elixir, Elm, Go, Rust, Java, Julia, and .NET. It can also update git submodules, Docker files, Opentofu, Terraform files and Pre-Commit hooks.

Features include:

• Check for the latest version of a dependency that's resolvable given a project's other dependencies
• Generate updated manifest and lockfiles for a new dependency version
• Generate PR descriptions that include the updated dependency's changelogs, release notes, and commits

How to run Dependabot

Most people are familiar with the Dependabot service that runs on GitHub.com and GitHub Enterprise. Enabling that is as

simple as checking a dependabot.yml configuration file in to your repository's .github directory.

However, if you want to run a custom version of Dependabot or run it on another platform, you're not left out in the cold.

This repo provides the logic necessary for hosting your own standalone Dependabot. It currently supports opening Pull Requests against repositories hosted on GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket, and AWS CodeCommit.

Dependabot-Core is a library, so you'll need an entrypoint script of some kind. Here are a few examples to help you get

started.

Note: If you're looking to run Dependabot locally for development/debugging purposes, see the Development Guide.

Dependabot CLI

The open-source Dependabot CLI is our recommended entrypoint for standalone use cases.

We use it in production here at GitHub, and advanced users can also leverage it to run a self-hosted version of Dependabot within their own projects / CI systems.

It creates dependency diffs but does not create PRs. So you will need to wire that up yourself.

To aid with that, we created the example-cli-usage repo which demonstrates how to turn those diffs into actual PR's.

Write your own Ruby-based tool

Alternatively, because Dependabot-Core is a Ruby library, you can write your own ruby-based wrapper that leverages the Dependabot-core code. The tricky bit is Dependabot assumes it's running in an isolated, throw-away environment so you'll need to handle all that yourself. For example protecting against security risks of arbitrary code execution exfiltrating credentials, ensuring the appropriate version of Go or Python or whatever language you need is available, and handling when Dependabot makes changes to its runtime environment.

Dependabot on CI

In an environment such as GitHub where Dependabot runs in a container, if you want to change your build or installation process depending on whether it's running within the context of the Dependabot container, you can check the existence of the DEPENDABOT environment variable.

Contributing to Dependabot

Reporting issues and Feature Requests

👋 Want to give us feedback on Dependabot, or contribute to it? That's great - thank you so much!

Reproducible Example

Most bug reports should be accompanied by a link to a public repository that reproduces the problem. Bug reports that

cannot be reproduced on a public repo using the CLI tool or dry-run script may be

closed as "cannot reproduce".

No "+1" Comments

Our issue tracker is quite active, and as a result there's a good chance someone already filed the same issue. If so,

please upvote that issue, because we use 👍 reactions on issues as one signal to gauge the impact of a feature request or bug.

However, please do not leave comments that contribute nothing new to the discussion. For details, see https://go.dev/wiki/NoPlusOne. This is open source, if you see something you want fixed, we are happy to coach you through contributing a pull request to fix it.

Don't file issues about Security Alerts or Dependency Graph

The issue-tracker is meant solely for issues related to Dependabot's updating logic. Issues about security alerts or Dependency Graph should instead be filed as a Code Security discussion.

A good rule of thumb is that if you have questions about the _diff_ in a PR, it belongs here.

Disclosing Security Issues

If you believe you have found a security vulnerability in Dependabot, please review our security policy for details about disclosing them to the GitHub Bug Bounty program, so we can work to resolve the issue before it is disclosed publicly.

Submitting Pull Requests

Want to contribute to Dependabot? That's great - thank you so much!

Contribution workflow:

1. Fork the project.
2. Get the development environment running.
3. Make your feature addition or bug fix.
4. Add tests for it. This is important so we don't break it in a future version unintentionally.
5. Send a pull request. The tests will run on it automatically, so don't worry if you couldn't get them running locally.

Please refer to the CONTRIBUTING guidelines for more information.

New Ecosystems

If you're interested in contributing support for a new ecosystem, please refer to the contributing guidelines for more information.

Development Guide

Getting a Development Environment Running

The first step to debugging a problem or writing a new feature is getting a development environment going. We provide a

custom Docker-based developer shell that bakes in all required dependencies.

In most cases this is the best way to work with the project.

The developer shell uses volume mounts to incorporate your local changes to Dependabot's source code. This way you can

edit locally using your favorite editor and the changes are immediately reflected within the docker container for performing

dry-runs or executing tests.

Note: See caveat about editing the native package manager helper scripts.

Quickstart

The script to launch the developer shell builds the docker images from scratch if it can't find them locally. This can take a while.

Skip the wait by pulling the pre-built image for the ecosystem you want to work on. The image name uses the YAML ecosystem name

to specify the ecosystem. For example, for Go Modules, the YAML name is gomod:

$ docker pull ghcr.io/dependabot/dependabot-updater-gomod

Note: Pre-built images are currently only available for AMD64 / Intel architecture. They _will_ run on ARM, but 2x-3x slower than if you manually build ARM-specific images.

Next, run the developer shell, specifying the desired ecosystem _using the top-level directory name of the ecosystem in this project_. For example, for Go Modules, the top-level directory is named go_modules:

$ bin/docker-dev-shell go_modules
=> running docker development shell
[dependabot-core-dev] ~ $ cd go_modules && rspec spec # to run tests for a particular package

Building Images from Scratch

Normally the Quickstart is all you need, but occasionally you'll need to rebuild the underlying images.

For example, while we don't yet publish ARM-specific images, if you _are_ working on an ARM-based platform, we recommend

manually building the images because the resulting containers run much faster.

The developer shell runs within a Dependabot Development docker image, which is built on top of an ecosystem image.

flowchart LR
    A["docker-dev-shell script"] --> B("Dependabot Development docker image")
    B --> C("Dependabot Updater Ecosystem docker image (ecosystem specific)")
    C --> D("Dependabot Updater Core docker image")

Changes to the docker files for any of these images requires building one or more of the images locally in order to be reflected in the development shell.

The simple but slow way is to delete any existing images and then run bin/docker-dev-shell which automatically builds

missing images.

The faster way is to pull all the pre-built images that are dependencies of the image you actually need to build.

To (re)build a specific one:

• The Updater core image:

  $ docker pull ghcr.io/dependabot/dependabot-updater-core # OR
  $ docker build -f Dockerfile.updater-core . --tag=dependabot-manual-build/updater-core # recommended on ARM

Each language/ecosystem sits on top of the core image. You need to rebuild whichever one you’re working on so it picks up your new core bits. For instance, if you’re working on Go Modules:

• The Updater ecosystem image:

  $ docker pull ghcr.io/dependabot/dependabot-updater-gomod # OR
  $ script/build go_modules # recommended on ARM

Or explicitly:

  $ docker build \
  --platform linux/amd64 \
  --file go_modules/Dockerfile \
  --build-arg UPDATER_CORE_IMAGE=dependabot-manual-build/updater-core \
  --tag dependabot-manual-build/updater-gomod \
  .

• Spin-up the development container using the --rebuild flag:

  $ bin/docker-dev-shell go_modules --rebuild

If successful, you should be inside the shell:

  => running docker development shell
  [dependabot-core-dev] ~ $

• Once inside the shell, you can run tests, e.g.:

  rspec common/spec/dependabot/file_fetchers/base_exclude_spec.rb

Making Changes to native Package Manager helpers

Several Dependabot packages make use of 'native helpers', small executables in their host language.

Changes to these files are not automatically reflected inside the development container.

Once you have made any edits to the helper files, run the appropriate build script to update the

installed version with your changes like so:

$ bin/docker-dev-shell bundler
=> running docker development shell
$ bundler/helpers/v2/build
$ bin/dry-run.rb bundler dependabot/demo --dir="/ruby"

To view logs and stdout from the native package manager helpers, see debugging native helpers.

Debugging Problems

The first step to debugging is getting the development environment running.

Within the development environment, you have two options for simulating a dependency update job:

You can use the newly-developed CLI tool or the original Dry-run script.

CLI tool

The Dependabot CLI is a newly-developed tool that incorporates the [GitHub

Credentials Proxy](#private-registry-credential-management) to more realistically simulate what's happening within

the Dependabot-at-GitHub service when talking to private registries.

It has a dedicated debugging guide, including support for dropping into the Ruby debugger.

Dry-Run Script

Note: Before running the dry-run script, you'll need to get the development environment running.

You can use the bin/dry-run.rb script to simulate a dependency update job, printing

the diff that would be generated to the terminal. It takes two positional

arguments: the package manager

and the GitHub repo name (including the account):

$ bin/docker-dev-shell go_modules
=> running docker development shell
$ bin/dry-run.rb go_modules rsc/quote
=> fetching dependency files
=> parsing dependency files
=> updating 2 dependencies
...

He