feat(gradle): bump strategy

[ldt-fweichert]

Changes

• added support for the bump strategy for gradle versioning using the maven style range syntax
• added support for maven style range syntax to the gradle manager
• repro repo

Todos

• Sign the CLA
• Fix last failling test
• Do code //TODO 's
• Get feedback on the implementation
• Add docs

Context

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

All committers have signed the CLA.

[Churro]

Thanks for the contribution. Looks promising but can benefit from some refinement:

• Please add a reproduction repo so that your changes can be tested against, incl a dep with regular maven based range and one with a range + strict version enforcement.
• Run prettier and undo changes unrelated to the bump strategy.
• Keep dep extraction to the minimum, it's not the place to decide what part to bump

Most importantly: To reduce the complexity of your changes, it would be great if you could limit this PR to the already supported Maven range syntax, for now ignoring gradle's strict version notation. This should allow you to reuse the existing maven range parsing, it should work without changes to the parser and, unless I missed something, only require a few adaptations in the gradle versioning

[Churro]

What's the intention here? Is it an attempt to add ! and a space to the list of allowed characters? If yes, this can be done simpler

[ldt-fweichert]

The intention was to allow ! and as chars, but only if they are not the last chars in the sequence. There were some false positives before i did this change

[Churro]

These chars need to be added to match gradle strict versions but the pattern you suggested doesn't protect against implausible versions. For ex., it still matches ! ! !-4. The current pattern doesn't protect against invalid versions like --2 either but as said this is not what is intended to be asserted here.

[ldt-fweichert]

I'm not quite sure i understood you correctly. Yes the the additions are there to also support the extended gradle maven syntax. As this is a maven-ranges only pull request, i've instead just added the space, because that is also supported by the maven syntax, and removed the test for checking if trailing spaces have an effect, because now they do (which is intended i guess).

[ldt-fweichert]

Thank you for the quick and precise feedback.

Most importantly: To reduce the complexity of your changes, it would be great if you could limit this PR to the already supported Maven range syntax, for now ignoring gradle's strict version notation. This should allow you to reuse the existing maven range parsing, it should work without changes to the parser and, unless I missed something, only require a few adaptations in the gradle versioning

The primary driver for this PR was the need for Gradle's strict version notation at my company. It allows us to specify: yes, you can use a newer dependency if you want, but if there are options to choose from, prefer the one specified with the '!!' Unfortunately, this functionality isn’t achievable without adding Gradle’s syntax.

Would your suggested path forward be to first implement Maven-only ranges (using the existing Maven module, which seems feasible), and then add Gradle syntax in a follow-up? If so, is there a way to minimize complexity and avoid lengthy delays? I work part-time (twice a week) and want to ensure this progresses smoothly without causing blockers.

[Churro]

Would your suggested path forward be to first implement Maven-only ranges (using the existing Maven module, which seems feasible), and then add Gradle syntax in a follow-up? If so, is there a way to minimize complexity and avoid lengthy delays? I work part-time (twice a week) and want to ensure this progresses smoothly without causing blockers.

Yes, the suggestion to do it in two iterations was exactly aimed at more efficient reviews: in a first PR focus on already parsed Maven ranges and add the bump strategy + composition of a new satisfying version to the gradle versioning part. In a second PR add ! and to versionLikeSubstring and extend the gradle versioning part with support for strict version definitions.

[ldt-fweichert]

I've adjusted this merge-request to match the new scope.

Please add a reproduction repo so that your changes can be tested against, incl a dep with regular maven based range and one with a range + strict version enforcement.

Is there a guide on how to do that or a pull request that had the same requirement where I could take a look at?

[Churro]

Regarding a minimal reproduction, take a look here -> https://github.com/renovatebot/renovate/blob/main/docs/development/minimal-reproductions.md

Please also rebase your changes on the current main branch.

[ldt-fweichert]

I did the changes you've suggest, the repro will have to wait until my next workday this week. Thanks for the link!

[Churro]

You may also want to add bump here:

renovate/lib/modules/versioning/gradle/index.ts

Line 21 in a6151da

export const supportedRangeStrategies: RangeStrategy[] = ['pin'];

[ldt-fweichert]

I am trying to get the repro running right now.
The repro repo is here
To verify that my test setup is working correctly i wanted to try the already implemented pin strategy on the main branch first. The weird thing is, that even that doesn't even seem to work. The version update fails due to a wrongly positioned fileReplacePosition:

Have i misconfigured something?
I am running renovate locally using pnpm debug ldt-fweichert/renotave-gradle-repro, nothing unusual there i guess.

[Churro]

Have i misconfigured something? I am running renovate locally using pnpm debug ldt-fweichert/renotave-gradle-repro, nothing unusual there i guess.

Your build.gradle.kts uses Unix line endings, so fileReplacePosition 814 is correct for io.ktor:ktor-server-netty:3.0.0. See https://github.com/renovatebot/renovate/blob/main/docs/development/best-practices.md#windows on how to resolve your CRLF issue.

[ldt-fweichert]

The bump strategy is working in my reproduction repo - thanks for the quick assistance! Should the documentation be updated to reflect this change somewhere?