Extended Gradle TOML support

[gmazzo]

What are you trying to accomplish?

Extends Gradle's Catalog support (.versions.toml files) to collect more file locations

Anything you want to highlight for special attention from reviewers?

Currently, dependabot will only consider gradle/libs.versions.toml file for pick dependencies. Even this may fit most of the standard cases, there some project setups that may require more catalog files.

The proposal is to support more cases:

• Any catalog under a root build (or included build) gradle folder: gradle/*.versions.toml, i.e.:
  • gradle/libs.versions.toml
  • gradle/buildSrc.versions.toml
  • gradle/shared.libs.versions.toml
  • buildSrc/gradle/libs.versions.toml
  • build-logic/gradle/libs.versions.toml
• Any catalog under a child module, i.e.:
  • app/libs.versions.toml
  • app/dependencies.versions.toml
  • module1/libs.versions.toml

Note

Even in theory, any .version.toml file could be potentially a dependency file, I just limited to extend some "convention locations" to limit the queries and prevent scanning the whole repo.

How will you know you've accomplished your goal?

Tests of gradle/file_fetcher.rb were updated, an its smoke-gradle-version-catalog.yaml as well

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[mowmanminer]

Here’s the full rundown on PR #12996 from the Dependabot Core repo:

📦 Pull Request: #12996 — Extended Gradle TOML support

---

🧠 Purpose

The PR expands Dependabot’s Gradle file discovery to handle multiple version catalog files (those .versions.toml files) beyond the default gradle/libs.versions.toml.
Right now, Dependabot only looks in that single location. This update enables it to detect dependency catalogs in many real-world Gradle project structures.

---

⚙️ What’s New

Current behavior:
Dependabot looks for dependencies only in:

gradle/libs.versions.toml

New behavior:
It will now include:

gradle/.versions.toml
buildSrc/gradle/.versions.toml
build-logic/gradle/.versions.toml
app/.versions.toml
module1/*.versions.toml

Essentially, any .versions.toml located inside gradle/ folders or module directories, following common conventions — without scanning the entire repo (for performance reasons).

Implementation highlights:

Adds new methods catalog_files and subproject_catalog_files in the Gradle FileFetcher to recursively discover TOML files in allowed directories.

Removes the old SUPPORTED_VERSION_CATALOG_FILE_PATH constant (hardcoded single path).

Updates tests for various Gradle project layouts to verify multi-catalog support.

Adjusts CI smoke tests to point to a new temporary smoke test repo/branch:

SMOKE_TEST_REPO: gmazzo/dependabot-smoke-tests
SMOKE_TEST_BRANCH: gradle-catalog-multiple

instead of the usual dependabot/smoke-tests main branch.

---

🧪 Test Additions

New integration tests confirm Dependabot can now pick up files like:

gradle/libs.versions.toml
gradle/buildSrc.versions.toml
app/libs.versions.toml

and correctly fetch dependencies from them.
Fixtures (contents_with_tomls.json, content_app_toml.json, etc.) simulate different Gradle repo structures.

---

✅ Status

Author: @gmazzo

Created: Sept 2, 2025

Updated: Sept 24, 2025

State: Open and mergeable

Checks: All tests and linting pass per author checklist.

---

🔍 Why It Matters

This update closes a major gap in Dependabot’s Gradle support.
Many large Gradle projects (especially Android and multi-module ones) use multiple version catalogs, and previously Dependabot ignored secondary catalogs — meaning missed dependency updates.

Now it’s far more compatible with real-world Gradle ecosystems while keeping scanning efficient.

---

If you’re testing this locally, you can confirm with:

gh pr checkout 12996
bundle exec rspec spec/dependabot/file_fetchers/java/gradle_spec.rb

That will verify the new catalog discovery logic across multiple Gradle setups.

[osvso]

Hi @gmazzo!
Thank you for the PR. I’m looking forward to getting this change in 💪

I’d like to propose a small extension to your change that would add support for ..versions.toml files located in the root project directory. Please let me know if you have any suggestions or objections.

[gmazzo]

located in the root project directory

I think I didn't documented it, but it should already be considering it, since catalog_files runs for each build.gradle.kts dir, including its root, and look for any .versions.toml file in there:
https://github.com/gmazzo/dependabot-core/blob/gradle-catalog-multiple/gradle/lib/dependabot/gradle/file_fetcher.rb#L265

[osvso]

@JamieMagee @markhallen Hello gents!
Could you help us out moving this PR forward?

[osvso]

@thavaahariharangit Hi!
It seems that this change is not high on the priority list. Anything I could do to help you get it to the finish line?

[dimitripantelli]

Hey, this is something I would find useful. I've been working on the same feature but with a slightly different approach: rather than scanning the repo to find catalogs in conventional locations, my implementation updates SettingsFileParser to parse catalogs explicitly declared in dependencyResolutionManagement.versionCatalogs. This means we can pick up catalogs at arbitrary paths and that these will be only the ones that Gradle actually uses.

The branch is here: https://github.com/dimitripantelli/dependabot-core/tree/multiple-version-catalog-support

Feel free to incorporate any of this if it's useful (or let me know if you'd like to collab). Unfortunately I missed this PR until I was about to open my own.

[gmazzo]

my implementation updates SettingsFileParser to parse catalogs explicitly declared in dependencyResolutionManagement.versionCatalogs.

That's even a more robust approach, to be honest. Feel free to push it instead of this one. This PR has lost its momentum, since it has not been reviewed in a long while.

Or if you want, open a PR to my fork to replace the implementation with yours, and we can reuse all the tests/smokes this PR has. Up to you.

I don't have much time to focus on this right now, but I still want to push for the change.

[dimitripantelli]

That's even a more robust approach, to be honest. Feel free to push it instead of this one. This PR has lost its momentum, since it has not been reviewed in a long while.

Thanks for the quick response and validation! Since you mentioned you're short on time, I've raised a PR (#14067) to keep things moving and avoid a bottleneck on your end. Will try and get this through.