mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-25 06:51:11 +00:00
RahulGautamSingh
23272951d6
* 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>