Support for Gradle composite builds

[zharinov]

What would you like Renovate to be able to do?

https://docs.gradle.org/current/userguide/composite_builds.html#composite_build_intro

Did you already have any implementation ideas?

• Recognition pattern may look like this: [a-zA-Z][a-zA-Z0-9]([vV]ersions|[dD]eps|...)\.kt
• Files should be processed after gradle.properties, but before build.gradle.kts
• Currently we use globally scoped variables, now we have to support multi-level scoping, e.g. Versions.Plugins.NODEJS
• Variables should be available for immediate string interpolation
• Dependency strings ("foo:bar:1.2.3") should be extracted as well, though evaluation should occur in the build.gradle.kts context
  • In future, this should help to deal with complex scoped user-defined repository rules (i.e. determine a valid registryUrl sequence)
  • When done for Versions.kt files, this mechanism should be applied for deps defined in gradle.properties as well

Example files:

• https://github.com/donbeave/graphql-java-datetime
  • buildSrc/src/main/java/Versions.kt
  • build.gradle.kts
  • Ref: https://github.com/donbeave/graphql-java-datetime/pull/39

More examples:

• radikushch/GAlertButton:dependencies/src/main/java/com/example/dependencies/GlobalVersions.kt
• square/okhttp:buildSrc/src/main/kotlin/deps.kt
• PokerAlpaka/kunde:buildSrc/src/main/kotlin/Versions.kt
• thewca/tnoodle:buildSrc/src/main/kotlin/dependencies/Versions.kt

[rarkins]

Do we need to discover these files using fileMatch or will the build.gradle reference them?

[rarkins]

Also, is this the same as #8692 ?

[zharinov]

Oh, I forgot about it. Yes, it is.

[rarkins]

Maybe close this as a duplicate and copy over the links from here

[HonkingGoose]

Duplicate of #8692

[zharinov]

Desired functionality turned to be a part of another feature

[zharinov]

Probably should be done before #8692

[Churro]

PR #21892 introduces parsing support for Kotlin source files with object declarations like object X { ... } and single variable assignments, such as val dep = "..."

As of now, renovate doesn't recognize composite plugins explicitly and if you place e.g. a Deps.kt into a composite plugin outside of buildSrc, renovate wouldn't capture it. However, with the parsing support added with #21892, .kt files of composite plugins can be parsed in an opt-in fashion.

E.g., the following renovate config would match a file like includedBuild/dependencies/src/main/kotlin/com/badoo/reaktive/dependencies/Deps.kt (ex. here):

  {
    "gradle": {
      "fileMatch": ["^includedBuild/.+\\.kt$"]
    }
  }

[mlschechter]

It looks like all the functionality requested here is addressed via other released modifications - is that correct?

[Churro]

It looks like all the functionality requested here is addressed via other released modifications - is that correct?

Yes and no. Everything that's mentioned in the examples above can already be matched by renovate. Matching .kt files works as described here (probably it would make sense to add this to the public docs btw).

What's currently not supported are actual composite builds, as illustrated here. So if you have a project that declares a binary dependency on a library that is included from a composite build, e.g., some:internal:1.0.0, you'll see a warning in the dependency dashboard if this dep is not yet present in one of the listed registries. In other words, there is no detection of composite builds per se.

To add real support for composite builds, it might be necessary to parse includeBuild directives from gradle settings. However, this info alone would be too imprecise to match composite builds, as you also need to know the current group and version, which are often only resolved at build time.