RahulGautamSingh 23272951d6 feat(manager/gradle): support rich version constraints in the Groovy/Kotlin DSL (#46498) ...

* refactor(manager/gradle): add helper for matching `group:artifact` strings

As part of follow-up changes, we'll extract dependencies whose version
is declared separately from their coordinates, so we need a way to
validate a bare `group:artifact` notation. `isDependencyString` can't
be used, as it requires a version to be present.

This isn't currently used.

Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>

* feat(manager/gradle): support rich version constraints in the Groovy/Kotlin DSL

As noted in discussion #45481, Renovate doesn't extract dependencies
whose version comes from a Gradle rich version constraint[0], so a
`strictly` pin never receives updates - not even for a security fix:

```groovy
dependencies {
    implementation('org.slf4j:slf4j-api') {
        version {
            strictly '[1.7, 1.8['
        }
    }
}
```

The version catalog extractor already handles rich versions, so the
missing piece is the `version { ... }` block in the Groovy and Kotlin
DSLs.

Renovate can only rewrite a single version literal per dependency, so
we pick one constraint to update and record which one in
`managerData.versionConstraint`:

- `strictly` -> bump `strictly`
- `strictly` (single version) + `prefer` -> bump `strictly`, as `prefer`
  is inert when there's nothing to choose between
- `require`, optionally with `prefer` -> bump `require`, as `prefer` is
  only a hint and may not be what gets resolved
- `prefer` alone -> bump `prefer`
- `require` + `strictly` -> skip as `multiple-constraint-dep`, as Gradle
  applies `require()` before `strictly()`, so bumping only `strictly`
  would leave the `require` literal behind as stale text
- `strictly` range + `prefer` -> skip as `multiple-constraint-dep`, as
  `prefer` has to keep pointing inside the range and we can't move both
- anything with `reject`/`rejectAll` -> skip as `unsupported-version`,
  matching what the version catalog extractor already does

As `strictly` and `prefer` pin a version on purpose, updating them by
default would be surprising, so those deps are extracted with
`enabled: false` - meaning they only receive updates for vulnerability
alerts, which force through. Users who want regular updates can opt in
with a package rule matching `managerData.versionConstraint`, similar to
how `manager/gomod` handles `depType: indirect`. A `require` constraint
means the same thing as a plain version declaration, so it is updated
like any other dependency.

This doesn't unify behaviour with version catalogs, which extract a
single `require`/`prefer`/`strictly` and update it without disabling it.
Aligning them would take away updates users get today, so that's left as
a separate decision.

The `!!` shorthand (i.e. `foo:bar:1.7.25!!`) is untouched - it already
extracts as an opaque version string. Rich versions declared in the
Groovy/Kotlin `versionCatalogs { }` builder, as opposed to TOML, are
still dropped silently.

[0]: https://docs.gradle.org/current/userguide/dependency_versions.html#sec:rich-version-constraints

Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>

* fix(vulnerabilities): raise fixes for deps their manager disables by default

* test(workers/fetch): set packageName on disabled-dep fixtures

* test(manager/gradle): assert enabled is not set

---------

Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>

2026-10-05 13:24:06 +00:00

..

development

chore(agents): give the stop hook its own coverage directory (#46586)

2026-10-01 06:59:46 +00:00

usage

feat(manager/gradle): support rich version constraints in the Groovy/Kotlin DSL (#46498)

2026-10-05 13:24:06 +00:00