Update to Error Prone 2.45.0 - #1401

NullAway has no automated dependency updates. Several entries in
gradle/libs.versions.toml are pinned on purpose and must not move:
errorProneOldest is the 2.36.0 minimum README.md documents,
errorProneJdk17 is the newest Error Prone that runs on JDK 17 because
2.43.0 and later require JDK 21 (uber#1401), and guava is the version
NullAway depends on while guava-latest tracks the newest release for
guava-recent-unit-tests (uber#629).

The obvious way to hold such an entry does not work. Renovate's gradle
manager declares versioning "gradle", whose ranges are [a,b), 1.2.+ and
[1.0]. There is no "<" form, so a bound of "< 2.43" in either
matchCurrentVersion or allowedVersions parses as nothing and holds
nothing back. The three Error Prone entries also resolve to the same
com.google.errorprone artifacts, so matchPackageNames cannot tell them
apart either.

Each pinned entry therefore gets a rule that matches on
sharedVariableName, the version-catalog alias Renovate records for a
dependency, and bounds it with a Gradle range: [,2.37) for
errorProneOldest, [,2.43) for errorProneJdk17, [,32) for guava. A patch
release inside the pin stays available, and a groupName keeps each entry
in a PR of its own, since group:monorepos, which config:recommended
brings in, would otherwise collect every com.google.errorprone
dependency into a single error-prone-monorepo PR. Everything else is
grouped the way Renovate already groups it, by version-catalog entry or
by upstream monorepo.

Three sets take no updates at all: the 1.0-HEAD-SNAPSHOT marker that
selects the current Error Prone snapshot, jmh/build.gradle, whose
caffeine, autodispose and nullaway versions appear as literal substrings
in its own classpath filters, and com.android.support, the legacy
Android support library.

PRs arrive every two weeks, except for Error Prone, which opens as soon
as a release lands. A major update goes to the dependency dashboard for
manual review instead of opening a PR.

The workflow runs renovate-config-validator on renovate.json, following
the model in pgjdbc. It passes --no-global, without which the validator
treats the file as a self-hosted global config and accepts options a
repository config may not carry. It carries no paths filter, because a
workflow that filters itself out reports no status and so could never be
a required check; the job runs on every pull request and every merge
queue entry instead, and skips the validation step when neither
renovate.json nor the workflow itself changed. One step carries no
condition at all: it checks that every catalog alias the rules pin is
still declared in gradle/libs.versions.toml, because a rename there
disables a rule while the config goes on validating, and the
change-detection step does not watch that file.

Checked with renovate --platform=local --dry-run=full: every pinned
entry is held, and widening each bound by hand produces the separate
branches the rules name. Renaming a catalog entry by hand fails the
alias check and names the entry.

Assisted-by: Claude Code (claude-opus-5)

NullAway has no automated dependency updates. uber#1817 proposed Dependabot
and was closed in favor of Renovate for its configuration options:
grouping every GitHub Actions bump into one pull request, and custom
regex managers for versions the standard managers do not reach.

Several versions in this build are pinned on purpose, and a bot that
bumped every one of them would break the test matrix:

* `errorProneOldest` holds the minimum Error Prone that `README.md`
  documents, 2.36.0, and `testErrorProneOldest` runs the suite against
  it. Raising that floor is a decision rather than maintenance, so the
  entry takes 2.36.x only.
* `errorProneJdk17` holds the newest Error Prone that runs on JDK 17,
  since 2.43.0 and later require JDK 21 (uber#1401), and `testJdk17` puts
  its jars in front of the test classpath. The entry takes 2.42.x only.
* `guava` is the version NullAway itself depends on, and it reaches a
  user's annotation processor path, so it stays on 31.x. The separate
  `guava-latest` entry that `guava-recent-unit-tests` uses keeps taking
  updates (uber#629).
* `errorProneLatestSnapshot` asks for the literal `1.0-HEAD-SNAPSHOT`
  marker, which Renovate reads as version 1.0 and would replace with a
  release.
* `jmh/build.gradle` pins the versions each benchmark was built with,
  and spells three of them as literal substrings in its classpath
  filters, so a bump would leave a filter matching nothing.
* `com.android.support` is the superseded Android support library, used
  only by `sample-app`.

The three Error Prone catalog entries resolve to the same
`com.google.errorprone` artifacts, and `guava` and `guava-latest` both
resolve to `com.google.guava:guava`, so `matchPackageNames` cannot tell
them apart. Those rules match on `sharedVariableName`, the catalog alias
Renovate reports for a dependency, under both spellings Renovate uses:
the bare alias, and the `libs.versions.` prefixed form it keeps for an
entry that `build.gradle` reads through an `ext` property. Each bound is
a Gradle range such as `[,2.37)`, because that versioning accepts
`[a,b)`, `1.2.+` and `[1.0]` and has no `<` form, so a bound written as
`< 2.37` would parse as nothing and hold nothing back. Each pinned entry
also carries a `groupName`, because otherwise `group:monorepos`, which
`config:recommended` brings in, would collect a pinned entry and an
unpinned one into one monorepo pull request. Everything else is grouped
the way Renovate already groups it, by version-catalog entry or by
upstream monorepo.

The rest is policy. Updates arrive every two weeks, labeled
`dependencies`, with no semantic-commit prefix, since this repository
writes plain subjects. A major update goes to the dependency dashboard
for manual approval instead of opening a pull request. Error Prone is
exempt from the schedule and opens as soon as a release is published:
NullAway compiles against Error Prone internals such as `ASTHelpers`,
and `testErrorProneLatestSnapshot` exists to catch such a change while
it is still a snapshot (uber#1555).

`renovate-config-validator` catches a malformed config and nothing else,
so the workflow also checks that every alias a rule pins is still
declared in `gradle/libs.versions.toml`; a rename there would leave the
rule matching nothing while the config still validated. That step
carries no `if:` condition, because the catalog is not one of the two
files the workflow watches for changes. The workflow itself carries no
`paths:` filter, so that its status is always reported and it can be
made a required check; the validation step is skipped instead when
neither `renovate.json` nor the workflow changed. The validator runs
with `--no-global`, without which it accepts self-hosted global options
such as `onboarding` that a repository config may not carry. The `on:`,
`concurrency:` and `permissions:` blocks are the ones uber#1818 settled on
for `continuous-integration.yml`.

This is configuration, so there are no unit tests. Checked with
`renovate --platform=local --dry-run=full` over this worktree, which
matched every rule against the real dependency set: each pinned entry is
held, and widening a bound by hand produces the separate branch its rule
names. Renaming a catalog entry by hand fails the alias check and names
the entry.

Left out, following the plan in uber#1792 to start with an initial version
and tune the rules later: automerge stays off, no custom regex manager
is configured yet, and the versions `jmh/build.gradle` and `sample-app`
pin are disabled outright rather than bounded. Merging this file does
not start Renovate; the app still has to be enabled for `uber/NullAway`.

Fixes uber#1792

Assisted-by: Claude Code (claude-opus-5)

NullAway has no automated dependency updates. uber#1817 proposed Dependabot
and was closed in favor of Renovate for its configuration options:
grouping every GitHub Actions bump into one pull request, and custom
regex managers for versions the standard managers do not reach.

Several versions in this build are pinned on purpose, and a bot that
bumped every one of them would break the test matrix:

* `errorProneOldest` holds the minimum Error Prone that `README.md`
  documents, 2.36.0, and `testErrorProneOldest` runs the suite against
  it. Raising that floor is a decision rather than maintenance, so the
  entry takes 2.36.x only.
* `errorProneJdk17` holds the newest Error Prone that runs on JDK 17,
  since 2.43.0 and later require JDK 21 (uber#1401), and `testJdk17` puts
  its jars in front of the test classpath. The entry takes 2.42.x only.
* `guava` is the version NullAway itself depends on, and it reaches a
  user's annotation processor path, so it stays on 31.x. The separate
  `guava-latest` entry that `guava-recent-unit-tests` uses keeps taking
  updates (uber#629).
* `errorProneLatestSnapshot` asks for the literal `1.0-HEAD-SNAPSHOT`
  marker, which Renovate reads as version 1.0 and would replace with a
  release.
* `jmh/build.gradle` pins every version it names, and spells three of
  them as literal substrings in its classpath filters, so a bump would
  leave a filter matching nothing.
* `com.android.support` is the superseded Android support library, used
  only by `sample-app`.

The three Error Prone catalog entries resolve to the same
`com.google.errorprone` artifacts, and `guava` and `guava-latest` both
resolve to `com.google.guava:guava`, so `matchPackageNames` cannot tell
them apart. Those rules match on `sharedVariableName`, the catalog alias
Renovate reports for a dependency, under both spellings Renovate uses:
the bare alias, and the `libs.versions.` prefixed form it keeps for an
entry that `build.gradle` reads through an `ext` property. Each bound is
a Gradle range such as `[,2.37)`, because that versioning accepts
`[a,b)`, `1.2.+` and `[1.0]` and has no `<` form, so a bound written as
`< 2.37` would parse as nothing and hold nothing back. Each pinned entry
also carries a `groupName`, because otherwise `group:monorepos`, which
`config:recommended` brings in, would collect a pinned entry and an
unpinned one into one monorepo pull request. Everything else is grouped
the way Renovate already groups it, by version-catalog entry or by
upstream monorepo.

The rest is policy. Updates arrive every two weeks, labeled
`dependencies`, with no semantic-commit prefix, since this repository
writes plain subjects. A major update goes to the dependency dashboard
for manual approval instead of opening a pull request. Error Prone is
exempt from the schedule and opens as soon as a release is published:
NullAway compiles against Error Prone internals such as `ASTHelpers`,
and `testErrorProneLatestSnapshot` (uber#1555) runs the suite against Error
Prone snapshots, so such a change shows up before the release does.

`renovate-config-validator` checks the config's shape, not whether a
rule still matches anything, so the workflow also checks that every
alias a rule pins is still declared in `gradle/libs.versions.toml`; a
rename there would leave the rule matching nothing while the config
still validated. That step carries no `if:` condition, because the
catalog is not one of the two files the workflow watches for changes.
The workflow itself carries no `paths:` filter, so that its status is
always reported and it can be made a required check; the validation step
is skipped instead when neither `renovate.json` nor the workflow
changed. The validator runs with `--no-global`, without which it accepts
self-hosted global options such as `onboarding` that a repository config
may not carry. The `merge_group` trigger and the `concurrency` group are
the ones uber#1818 settled on for `continuous-integration.yml`.

This is configuration, so there are no unit tests. Checked with
`renovate --platform=local --dry-run=full` over this worktree, which
matched every rule against the real dependency set: each pinned entry is
held, and widening a bound by hand produces the separate branch its rule
names. Renaming a catalog entry by hand fails the alias check and names
the entry.

Left out, following the plan in uber#1792 to start with an initial version
and tune the rules later: automerge stays off, no custom regex manager
is configured yet, and `jmh/build.gradle` and `com.android.support` are
disabled outright rather than bounded. Merging this file does not start
Renovate; the app still has to be enabled for `uber/NullAway`.

Fixes uber#1792

Assisted-by: Claude Code (claude-opus-5)

NullAway has no automated dependency updates. uber#1817 proposed Dependabot
and was closed in favor of Renovate for its configuration options:
grouping every GitHub Actions bump into one pull request, and custom
regex managers for versions the standard managers do not reach.

Several versions in this build are pinned on purpose, and a bot that
bumped every one of them would break the test matrix:

* `errorProneOldest` holds the minimum Error Prone that `README.md`
  documents, 2.36.0, and `testErrorProneOldest` runs the suite against
  it. Raising that floor is a decision rather than maintenance, so the
  entry takes 2.36.x only.
* `errorProneJdk17` holds the newest Error Prone that runs on JDK 17,
  since 2.43.0 and later require JDK 21 (uber#1401), and `testJdk17` puts
  its jars in front of the test classpath. The entry takes 2.42.x only.
* `guava` is the version NullAway itself depends on, and it reaches a
  user's annotation processor path, so it stays on 31.x. The separate
  `guava-latest` entry that `guava-recent-unit-tests` uses keeps taking
  updates (uber#629).
* `errorProneLatestSnapshot` asks for the literal `1.0-HEAD-SNAPSHOT`
  marker, which Renovate reads as version 1.0 and would replace with a
  release.
* `jmh/build.gradle` pins every version it names, and spells three of
  them as literal substrings in its classpath filters, so a bump would
  leave a filter matching nothing.
* `com.android.support` is the superseded Android support library, used
  only by `sample-app`.

The three Error Prone catalog entries resolve to the same
`com.google.errorprone` artifacts, and `guava` and `guava-latest` both
resolve to `com.google.guava:guava`, so `matchPackageNames` cannot tell
them apart. Those rules match on `sharedVariableName`, the catalog alias
Renovate reports for a dependency, under two spellings. Renovate reports
the bare alias for every entry in this repository; the `libs.versions.`
prefixed form is insurance, for an entry that `build.gradle` reads
through an `ext` property and that a refactor leaves with a single
dependency. Each bound is a Gradle range such as `[,2.37)`, because that
versioning accepts `[a,b)`, `1.2.+` and `[1.0]` and has no `<` form, so
a bound written as `< 2.37` would parse as nothing and hold nothing
back. Each pinned entry also carries a `groupName`, because otherwise
`group:monorepos`, which `config:best-practices` pulls in through
`config:recommended`, would collect a pinned entry and an unpinned one
into one monorepo pull request. Everything else is grouped the way
Renovate already groups it, by version-catalog entry or by upstream
monorepo.

The rest is policy. Updates arrive every two weeks, labeled
`dependencies`, with no semantic-commit prefix, since this repository
writes plain subjects. A major update goes to the dependency dashboard
for manual approval instead of opening a pull request. Error Prone is
exempt from the schedule and opens as soon as a release is published:
NullAway compiles against Error Prone internals such as `ASTHelpers`,
and `testErrorProneLatestSnapshot` (uber#1555) runs the suite against Error
Prone snapshots, so such a change shows up before the release does.

`renovate-config-validator` checks the config's shape, not whether a
rule still matches anything, so the workflow also checks that every
alias a rule pins is still declared in `gradle/libs.versions.toml`; a
rename there would leave the rule matching nothing while the config
still validated. That step carries no `if:` condition, because the
catalog is not one of the two files the workflow watches for changes.
The workflow itself carries no `paths:` filter, so that its status is
always reported and it can be made a required check; the validation step
is skipped instead when neither `renovate.json` nor the workflow
changed. The validator runs with `--no-global`, without which it accepts
self-hosted global options such as `onboarding` that a repository config
may not carry. The `merge_group` trigger and the `concurrency` group are
the ones uber#1818 settled on for `continuous-integration.yml`.

This is configuration, so there are no unit tests. Checked with
`renovate --platform=local --dry-run=full` over this worktree, which
matched every rule against the real dependency set: each pinned entry is
held, and widening a bound by hand produces the separate branch its rule
names. Renaming a catalog entry by hand fails the alias check and names
the entry.

Left out, following the plan in uber#1792 to start with an initial version
and tune the rules later. Automerge stays off and no custom regex
manager is configured yet. The GitHub Actions grouping covers
`actions/*` and `github/*`, not the other publishers this repository
uses, so a `codecov`, `gradle/actions` or `zizmorcore` bump still
arrives on its own. The older test fixtures in
`gradle/libs.versions.toml` are not excluded either: nothing in the
repository records which of them are held on purpose, so their majors
need dashboard approval and their minors will open pull requests until
someone names the ones to pin. `jmh/build.gradle` and
`com.android.support` are disabled outright rather than bounded. Merging
this file does not start Renovate; the app still has to be enabled for
`uber/NullAway`.

Fixes uber#1792

Assisted-by: Claude Code (claude-opus-5)

NullAway has no automated dependency updates. uber#1817 proposed Dependabot
and was closed in favor of Renovate for its configuration options:
grouping every GitHub Actions bump into one pull request, and custom
regex managers for versions the standard managers do not reach.

Several versions in this build are pinned on purpose, and a bot that
bumped every one of them would break the test matrix:

* `errorProneOldest` holds the minimum Error Prone that `README.md`
  documents, 2.36.0, and `testErrorProneOldest` runs the suite against
  it. Raising that floor is a decision rather than maintenance, so the
  entry takes 2.36.x only.
* `errorProneJdk17` holds the newest Error Prone that runs on JDK 17,
  since 2.43.0 and later require JDK 21 (uber#1401), and `testJdk17` puts
  its jars in front of the test classpath. The entry takes 2.42.x only.
* `guava` is the version NullAway itself depends on, and it reaches a
  user's annotation processor path, so it stays on 31.x. The separate
  `guava-latest` entry that `guava-recent-unit-tests` uses keeps taking
  updates (uber#629).
* `errorProneLatestSnapshot` asks for the literal `1.0-HEAD-SNAPSHOT`
  marker, which Renovate reads as version 1.0 and would replace with a
  release.
* `jmh/build.gradle` pins every version it names, and spells three of
  them as literal substrings in its classpath filters, so a bump would
  leave a filter matching nothing.
* `com.android.support` is the superseded Android support library, used
  only by `sample-app`.

The three Error Prone catalog entries resolve to the same
`com.google.errorprone` artifacts, and `guava` and `guava-latest` both
resolve to `com.google.guava:guava`, so `matchPackageNames` cannot tell
them apart. Those rules match on `sharedVariableName`, the catalog alias
Renovate reports for a dependency, under two spellings. Renovate reports
the bare alias for every entry in this repository; the `libs.versions.`
prefixed form is insurance, for an entry that `build.gradle` reads
through an `ext` property and that a refactor leaves with a single
dependency. Each bound is a Gradle range such as `[,2.37)`, because that
versioning accepts `[a,b)`, `1.2.+` and `[1.0]` and has no `<` form, so
a bound written as `< 2.37` would parse as nothing and hold nothing
back. Each pinned entry also carries a `groupName`, because otherwise
`group:monorepos`, which `config:best-practices` pulls in through
`config:recommended`, would collect a pinned entry and an unpinned one
into one monorepo pull request. Everything else is grouped the way
Renovate already groups it, by version-catalog entry or by upstream
monorepo.

The rest is policy. Updates arrive every two weeks, labeled
`dependencies`, with no semantic-commit prefix, since this repository
writes plain subjects. A major update goes to the dependency dashboard
for manual approval instead of opening a pull request, Error Prone
included; only the schedule and the cooldown below treat Error Prone
differently. It is exempt from the schedule and opens as soon as a
release is published: NullAway compiles against Error Prone internals
such as `ASTHelpers`, and `testErrorProneLatestSnapshot` (uber#1555) runs
the suite against Error Prone snapshots, so such a change shows up
before the release does.

A release less than seven days old does not reach a pull request:
`minimumReleaseAge` holds it back, so that a broken or compromised
publish has time to be found and pulled. Where an older release above
the current version is itself old enough, Renovate targets that one
rather than waiting. Error Prone and the actions GitHub publishes are
exempt, because a broken Error Prone release breaks this build rather
than reaching users and `testErrorProneLatestSnapshot` has already
exercised it as a snapshot, and because an action GitHub publishes is
not the supply-chain risk a third-party one is. A security update
bypasses the cooldown through Renovate's own `vulnerabilityAlerts`
defaults.

`renovate-config-validator` checks the config's shape, not whether a
rule still matches anything, so the workflow also checks that every
alias a rule pins is still declared in `gradle/libs.versions.toml`; a
rename there would leave the rule matching nothing while the config
still validated. That step carries no `if:` condition, because the
catalog is not one of the two files the workflow watches for changes.
The workflow itself carries no `paths:` filter, so that its status is
always reported and it can be made a required check; the validation step
is skipped instead when neither `renovate.json` nor the workflow
changed. The validator runs with `--no-global`, without which it accepts
self-hosted global options such as `onboarding` that a repository config
may not carry. The `merge_group` trigger and the `concurrency` group are
the ones uber#1818 settled on for `continuous-integration.yml`.

This is configuration, so there are no unit tests. Checked with
`renovate --platform=local --dry-run=full` over this worktree, which
matched every rule against the real dependency set: each pinned entry is
held, and widening a bound by hand produces the separate branch its rule
names. Renaming a catalog entry by hand fails the alias check and names
the entry. The cooldown was measured the same way: at seven days two
updates are held as pending and three retarget to an older release that
is old enough, and raising it to 365 days holds twenty while the exempt
Error Prone update still comes through. No run covers GitHub Actions: a
local Renovate has no token, so all 21 action dependencies come back
`github-token-required`.

Left out, following the plan in uber#1792 to start with an initial version
and tune the rules later. Automerge stays off and no custom regex
manager is configured yet. The GitHub Actions grouping covers
`actions/*` and `github/*`, not the other publishers this repository
uses, so a `codecov`, `gradle/actions` or `zizmorcore` bump still
arrives on its own. The older test fixtures in
`gradle/libs.versions.toml` are not excluded either: nothing in the
repository records which of them are held on purpose, so their majors
need dashboard approval and their minors will open pull requests until
someone names the ones to pin. `jmh/build.gradle` and
`com.android.support` are disabled outright rather than bounded. Merging
this file does not start Renovate; the app still has to be enabled for
`uber/NullAway`.

Fixes uber#1792

Assisted-by: Claude Code (claude-opus-5)

NullAway has no automated dependency updates. #1817 proposed Dependabot
and was closed in favor of Renovate for its configuration options:
grouping every GitHub Actions bump into one pull request, and custom
regex managers for versions the standard managers do not reach.

Several versions in this build are pinned on purpose, and a bot that
bumped every one of them would break the test matrix:

* `errorProneOldest` holds the minimum Error Prone that `README.md`
documents, 2.36.0, and `testErrorProneOldest` runs the suite against it.
Raising that floor is a decision rather than maintenance, so the entry
takes 2.36.x only.
* `errorProneJdk17` holds the newest Error Prone that runs on JDK 17,
since 2.43.0 and later require JDK 21 (#1401), and `testJdk17` puts its
jars in front of the test classpath. The entry takes 2.42.x only.
* `guava` is the version NullAway itself depends on, and it reaches a
user's annotation processor path, so it stays on 31.x. The separate
`guava-latest` entry that `guava-recent-unit-tests` uses keeps taking
updates (#629).
* `errorProneLatestSnapshot` asks for the literal `1.0-HEAD-SNAPSHOT`
marker, which Renovate reads as version 1.0 and would replace with a
release.
* `jmh/build.gradle` pins every version it names, and spells three of
them as literal substrings in its classpath filters, so a bump would
leave a filter matching nothing.
* `com.android.support` is the superseded Android support library, used
only by `sample-app`.

The three Error Prone catalog entries resolve to the same
`com.google.errorprone` artifacts, and `guava` and `guava-latest` both
resolve to `com.google.guava:guava`, so `matchPackageNames` cannot tell
them apart. Those rules match on `sharedVariableName`, the catalog alias
Renovate reports for a dependency, under two spellings. Renovate reports
the bare alias for every entry in this repository; the `libs.versions.`
prefixed form is insurance, for an entry that `build.gradle` reads
through an `ext` property and that a refactor leaves with a single
dependency. Each bound is a Gradle range such as `[,2.37)`, because that
versioning accepts `[a,b)`, `1.2.+` and `[1.0]` and has no `<` form, so
a bound written as `< 2.37` would parse as nothing and hold nothing
back. Each pinned entry also carries a `groupName`, because otherwise
`group:monorepos`, which `config:best-practices` pulls in through
`config:recommended`, would collect a pinned entry and an unpinned one
into one monorepo pull request. Everything else is grouped the way
Renovate already groups it, by version-catalog entry or by upstream
monorepo.

The rest is policy. Updates arrive every two weeks, labeled
`dependencies`, with no semantic-commit prefix, since this repository
writes plain subjects. A major update goes to the dependency dashboard
for manual approval instead of opening a pull request, Error Prone
included; only the schedule and the cooldown below treat Error Prone
differently. It is exempt from the schedule and opens as soon as a
release is published: NullAway compiles against Error Prone internals
such as `ASTHelpers`, and `testErrorProneLatestSnapshot` (#1555) runs
the suite against Error Prone snapshots, so such a change shows up
before the release does.

A release less than seven days old does not reach a pull request:
`minimumReleaseAge` holds it back, so that a broken or compromised
publish has time to be found and pulled. Where an older release above
the current version is itself old enough, Renovate targets that one
rather than waiting. Error Prone and the actions GitHub publishes are
exempt, because a broken Error Prone release breaks this build rather
than reaching users and `testErrorProneLatestSnapshot` has already
exercised it as a snapshot, and because an action GitHub publishes is
not the supply-chain risk a third-party one is. A security update
bypasses the cooldown through Renovate's own `vulnerabilityAlerts`
defaults.

`renovate-config-validator` checks the config's shape, not whether a
rule still matches anything, so the workflow also checks that every
alias a rule pins is still declared in `gradle/libs.versions.toml`; a
rename there would leave the rule matching nothing while the config
still validated. That step carries no `if:` condition, because the
catalog is not one of the two files the workflow watches for changes.
The workflow itself carries no `paths:` filter, so that its status is
always reported and it can be made a required check; the validation step
is skipped instead when neither `renovate.json` nor the workflow
changed. The validator runs with `--no-global`, without which it accepts
self-hosted global options such as `onboarding` that a repository config
may not carry. The `merge_group` trigger and the `concurrency` group are
the ones #1818 settled on for `continuous-integration.yml`.

This is configuration, so there are no unit tests. Checked with
`renovate --platform=local --dry-run=full` over this worktree, which
matched every rule against the real dependency set: each pinned entry is
held, and widening a bound by hand produces the separate branch its rule
names. Renaming a catalog entry by hand fails the alias check and names
the entry. The cooldown was measured the same way: at seven days two
updates are held as pending and three retarget to an older release that
is old enough, and raising it to 365 days holds twenty while the exempt
Error Prone update still comes through. No run covers GitHub Actions: a
local Renovate has no token, so all 21 action dependencies come back
`github-token-required`.

Left out, following the plan in #1792 to start with an initial version
and tune the rules later. Automerge stays off and no custom regex
manager is configured yet. The GitHub Actions grouping covers
`actions/*` and `github/*`, not the other publishers this repository
uses, so a `codecov`, `gradle/actions` or `zizmorcore` bump still
arrives on its own. The older test fixtures in
`gradle/libs.versions.toml` are not excluded either: nothing in the
repository records which of them are held on purpose, so their majors
need dashboard approval and their minors will open pull requests until
someone names the ones to pin. `jmh/build.gradle` and
`com.android.support` are disabled outright rather than bounded. Merging
this file does not start Renovate; the app still has to be enabled for
`uber/NullAway`.

Fixes #1792

Assisted-by: Claude Code (claude-opus-5)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Chores**
- Added automated Renovate configuration to regularly identify and group
dependency updates.
- Dependency updates now follow release-age safeguards, version
constraints, and approval requirements for major changes.
- Added validation checks to ensure Renovate configuration remains
consistent and valid across pull requests, merge queues, and pushes.
  - GitHub Actions updates are grouped together to simplify maintenance.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->