manager(gradle): do not bump dependency constraints

[abelsromero]

Tell us more.

For context:
Currently running self-hosted GitHub.

---

Gradle offers two ways to handle transitive dependencies:

• constraints: https://docs.gradle.org/current/userguide/dependency_constraints.html#sec:adding-constraints-transitive-deps
• resolutionStrategy: https://docs.gradle.org/current/userguide/dependency_locking.html#locking_specific_configurations, for a more programmatic approach, useful to handle multiple dependencies at once.

Both offer a clean way to bump a version and document the reason. For example, when dealing with CVEs one can have something like this and make sure all modules in the project use that version.

constraints {
    implementation("com.squareup.okio:okio:3.4.0") {
        because 'patch CVE-2023-3635'
    }
}

Later, as part of maintenance, one can check when a contains is no longer necessary and remove it.

---

However, Renovate also bumps those dependencies, which means:
a) user needs to close the PR (if it's not merged automatically)
b) the "code as documentation" no longer applies since the version won't match the actual containing the fix
c) simply accept it and keep track of the original fix some other way. That makes maintenance and removal harder.

---

That's why I think such dependent definitions should not be bumped automatically. At least a way to avoid it should be provided.
And dreaming, if Renovate could even remove then when not necessary that would be amazing.

[Churro]

You always have the option to disable renovate updates for certain dependencies via package rules.

• CVE fixes usually don't apply to only to one particular version but also to all higher versions from there on (unless there is a regression).
• constraints in gradle allow you to force that all transitive deps use at least the version indicated by the constraint. During dependency resolution, gradle may still pick a higher version, unless you really force a version, e.g., via version { strictly '3.4.0' }
• By running renovate on deps specified in constraints blocks, you'll also get fix PRs if new vulnerabilities become known for these versions.

[abelsromero]

You always have the option to disable renovate updates for certain dependencies via package rules.

But the end goal is to reduce manual work, having to handle constraints and ignores actually increases it.

CVE fixes usually don't apply to only to one particular version but also to all higher versions from there on (unless there is a regression).

That's fine, but then we lose the documentation side of the constraint that refers to the actual reason for that version. Plus, eventually, the bump won't be necessary as direct dependencies catch up, but we'll still be getting PRs that require attention. For context, we run heavy pipelines that run on multiple environments and take hours. Being able to reduce PRs that are not necessary is a big deal.

constraints in gradle allow you to force that all transitive deps use at least the version indicated by the constraint. During dependency resolution, gradle may still pick a higher version, unless you really force a version, e.g., via version { strictly '3.4.0' }

We use that in some cases, but it cannot be applied as a general solution. Due to other policies, and especially not being supported in resolutionStrategy.

By running renovate on deps specified in constraints blocks, you'll also get fix PRs if new vulnerabilities become known for these versions.

This is maybe another conversation, but I think any security consideration should be picked by a security scanner.
That's our case, if a constraint needs to be bumped it's notified and we can update it alongside the description.
I can imagine ppl not caring about the documentation and wanting all bumps, in that case maye making this feature requests an option would make sense.

[Churro]

You always have the option to disable renovate updates for certain dependencies via package rules.

But the end goal is to reduce manual work, having to handle constraints and ignores actually increases it.

Not necessarily. If you manage constraints in a separate gradle file and include it via apply from, you can exempt the entire file in your renovate config using ignorePaths.