Hello everyone! Is it possible somehow to have access to a function defined in the `build-logic` (in...

# gradle

[Nick Kleban]

Hello everyone!
Is it possible somehow to have access to a function defined in the build-logic (included build) inside app/build.gradle.kts in the plugins { } block?

I have function that looks like

fun isCI() = System.getenv("GITLAB_CI").toBoolean()

And I can use it in the app/build.gradle.kts everywhere except plugins block where I get “Unresolved reference” error

plugins {
    alias(libs.plugins...) apply isCI()
}

[Vampire]

No, the plugins { ... } block is extracted and evaluated separately, there your build logic is not yet available. That block actually depends on your plugin and thus adds it to the class path, so you cannot use things inside due to hen-and-egg problem.

[Nick Kleban]

Any workarounds for this issue?
Currently I’m making custom plugin in build-logic that wraps original plugin and makes this check and apply inside but maybe there is some better approach.

[ephemient]

conditionally applying plugins seems like a bad idea to begin with. that leads to conditionally valid buildscripts too

[ephemient]

better to push the isCI() check down into task.onlyIf {} etc.

[Nick Kleban]

I want to disable some plugins on my local PC to speed up local builds. It works in my case as I don’t use the content added by the plugins explicitly and I can safely disable them without breaking the build. Those plugins adds its own tasks to the assemble task finalizedBy block implicitly and the only way around it is either disable the plugin or remove\disable tasks added by the plugin. First way seems better to me as I don’t need to know anything about plugin internals.

[mbonnin]

You can add your plugin to the plugins {} block without applying it:

plugins {
  id("com.example").apply(false)
}

And then apply it in your build script

if (isCI()) {
  plugins.apply("com.example")
}

[mbonnin]

You won't have any of the auto generated accessors but if what you want is speed, you might be able to live with this

[Vampire]

If what you want is speed, better make as much cacheable as possible, make sure task-configuration avoidance is not broken, and make your build use configuration cache. Then you most probably do not feel the need for such hacks. 🙂

[mbonnin]

fair enough, I'm just giving out the options 😄

[mbonnin]

configuration cache in CI isn't much of a thing yet though, is it?

[Vampire]

He wants local speed, whether you can enable CC on CI should be irrelevant here 🙂

[Vampire]

But depending on situation you might even be able to use CC on CI

[mbonnin]

but cc will work the same locally without the plugin applied, right?

[mbonnin]

As long as System.getenv("CI") is always the same value, CC can be reused

[Nick Kleban]

@mbonnin I’ve done it already, just trying to push a little bit further 🙂 It seems like some plugin tasks are not cacheable and some doing network requests (though it can be disabled trough plugin options)

[mbonnin]

Also you save generating the accessors blob upside down

[Vampire]

but cc will work the same locally without the plugin applied, right?

Sure, I just meant that you can do without having different builds on CI and locally which is always potential for differences and thus f***up - if not now then in the future - when everything you want is local speed and making the build use CC locally is enough.

[mbonnin]

The day we have remote CC then it'll be slower

[mbonnin]

(it'll be slower to apply plugins conditionnally because then you can't reuse CC in the CI machine, but that's in the future... and benchmarking is hard so better measure all this)

[Vampire]

Ah, now I see what you mean.
Yeah, you can also not reuse the CI CC locally then.

[Nick Kleban]

Thank you guys for the insights!