Skip to content

chore(config): migrate renovate config #7200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 11, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
147 changes: 82 additions & 65 deletions renovate.json5
Original file line number Diff line number Diff line change
@@ -1,72 +1,85 @@
{
"extends": [
"config:base",
":semanticCommits",
extends: [
'config:recommended',
':semanticCommits',
],
// Renovate Regex Manager Configuration
//
// A slight variation on the pattern documented within Renovate's docs:
//
// => https://docs.renovatebot.com/modules/manager/regex/
//
// This powers a mechanism that allows Renovate (the package dependency
// manager that we use within this repository) to bump packages that live
// outside of typical package manifests (e.g., `package.json`) and instead
// any number of files.
//
// This pattern can be conceivably adapted to any pattern to allow the
// "Renovation" of nearly anything. This is largely what Renovate does
// behind the scenes for various datasources anyhow (e.g., Dockerfiles).
//
// You can find a list of data-source specific details on this page:
//
// => https://docs.renovatebot.com/modules/datasource/
//
"regexManagers": [
customManagers: [
// Renovate Regex Manager Configuration
//
// A slight variation on the pattern documented within Renovate's docs:
//
// => https://docs.renovatebot.com/modules/manager/regex/
//
// This powers a mechanism that allows Renovate (the package dependency
// manager that we use within this repository) to bump packages that live
// outside of typical package manifests (e.g., `package.json`) and instead
// any number of files.
//
// This pattern can be conceivably adapted to any pattern to allow the
// "Renovation" of nearly anything. This is largely what Renovate does
// behind the scenes for various datasources anyhow (e.g., Dockerfiles).
//
// You can find a list of data-source specific details on this page:
//
// => https://docs.renovatebot.com/modules/datasource/
//
{
"fileMatch": [
"^\\.tool-versions$",
"(^|/)Dockerfile[^/]*$",
"^rust-toolchain\\.toml$",
"^docs/.*?\\.mdx$"
customType: 'regex',
fileMatch: [
'^\\.tool-versions$',
'(^|/)Dockerfile[^/]*$',
'^rust-toolchain\\.toml$',
'^docs/.*?\\.mdx$',
],
"matchStrings": [
"(#|<!--)\\s*renovate-automation: rustc version\\s*(?:-->)?\\n[^.]*?(?<currentValue>[0-9]+\\.[0-9]+\\.[0-9]+)\\b"
matchStrings: [
'(#|<!--)\\s*renovate-automation: rustc version\\s*(?:-->)?\\n[^.]*?(?<currentValue>[0-9]+\\.[0-9]+\\.[0-9]+)\\b',
],
"depNameTemplate": "rust",
"datasourceTemplate": "docker"
}
depNameTemplate: 'rust',
datasourceTemplate: 'docker',
},
],
"packageRules": [
packageRules: [
// Don't do `rust` image updates on Dockerfiles since they'll we want them
// managed/grouped into the package rule directly after this one. This
// prevents multiple PRs for the same bump, and puts all our Rust version
// bumps together.
{
"matchPackageNames": ["rust"],
"matchManagers": ["dockerfile"],
"enabled": false
matchPackageNames: [
'rust',
],
matchManagers: [
'dockerfile',
],
enabled: false,
},
{
// This "rust" name maps to the Docker Hub "rust" image above on account
// of the `regexManagers[0]` defined above being `datasourceTemplate` = `docker`.
"matchPackageNames": ["rust"],
"matchManagers": "regex",
"groupName": "rustc",
"branchName": "{{{branchPrefix}}}rustc"
matchPackageNames: [
'rust',
],
matchManagers: 'regex',
groupName: 'rustc',
branchName: '{{{branchPrefix}}}rustc',
},
// Bunch up all non-major dependencies into a single PR. In the common case
// where the upgrades apply cleanly, this causes less noise and is resolved faster
// than starting a bunch of upgrades in parallel for what may turn out to be
// a suite of related packages all released at once.
{
"matchCurrentVersion": ">= 1.0.0",
"matchManagers": [ "cargo", "npm" ],
"excludePackageNames": [],
"matchUpdateTypes": ["minor", "patch", "pin", "digest"],
"groupName": "all non-major packages >= 1.0",
"groupSlug": "all-non-major-gte-1.0",
"automerge": true,
matchCurrentVersion: '>= 1.0.0',
matchManagers: [
'cargo',
'npm',
],
matchUpdateTypes: [
'minor',
'patch',
'pin',
'digest',
],
groupName: 'all non-major packages >= 1.0',
groupSlug: 'all-non-major-gte-1.0',
automerge: true,
matchPackageNames: [],
},
// We're currently constrained in our ability to update the `tracing`
// packages to the latest versions because of our usage. As an extension
Expand All @@ -77,28 +90,32 @@
// in the `/apollo-router/Cargo.toml` file around the declarations for
// `^opentelemetry` and `^tracing` packages.
{
"matchManagers": [
"cargo"
matchManagers: [
'cargo',
],
"matchPackagePatterns": [
"^tracing",
"^opentelemetry",
groupName: 'cargo tracing packages',
groupSlug: 'cargo-tracing-packages',
dependencyDashboardApproval: true,
matchPackageNames: [
'/^tracing/',
'/^opentelemetry/',
],
"groupName": "cargo tracing packages",
"groupSlug": "cargo-tracing-packages",
"dependencyDashboardApproval": true
},
// Our own `apollo-` packages deserve to get front-and-center treatment.
// We'll put them in their own PR to facilitate workflows that surface
// their changes earlier, and get us dog-fooding them quicker.
// They also have a small proclivity to require more hands-on changes
// since they're pre-0.x and we use them so extensively.
{
"matchPackagePatterns": ["^apollo-"],
"groupName": "apollo-rs crates",
"groupSlug": "rust-apollo-rs-updates",
"matchManagers": ["cargo"],
"automerge": false
}
]
groupName: 'apollo-rs crates',
groupSlug: 'rust-apollo-rs-updates',
matchManagers: [
'cargo',
],
automerge: false,
matchPackageNames: [
'/^apollo-/',
],
},
],
}