https://kotlinlang.org logo
#gradle
Title
# gradle
n

Nick Kleban

11/21/2023, 9:03 AM
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
Copy code
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
Copy code
plugins {
    alias(libs.plugins...) apply isCI()
}
v

Vampire

11/21/2023, 9:07 AM
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.
n

Nick Kleban

11/21/2023, 9:13 AM
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.
e

ephemient

11/21/2023, 9:15 AM
conditionally applying plugins seems like a bad idea to begin with. that leads to conditionally valid buildscripts too
better to push the
isCI()
check down into
task.onlyIf {}
etc.
n

Nick Kleban

11/21/2023, 9:29 AM
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.
m

mbonnin

11/21/2023, 9:50 AM
You can add your plugin to the
plugins {}
block without applying it:
Copy code
plugins {
  id("com.example").apply(false)
}
And then apply it in your build script
Copy code
if (isCI()) {
  plugins.apply("com.example")
}
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
v

Vampire

11/21/2023, 10:04 AM
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. 🙂
m

mbonnin

11/21/2023, 10:05 AM
fair enough, I'm just giving out the options 😄
configuration cache in CI isn't much of a thing yet though, is it?
v

Vampire

11/21/2023, 10:08 AM
He wants local speed, whether you can enable CC on CI should be irrelevant here 🙂
But depending on situation you might even be able to use CC on CI
m

mbonnin

11/21/2023, 10:08 AM
but cc will work the same locally without the plugin applied, right?
As long as
System.getenv("CI")
is always the same value, CC can be reused
n

Nick Kleban

11/21/2023, 10:09 AM
@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)
👍 1
m

mbonnin

11/21/2023, 10:09 AM
Also you save generating the accessors blob upside down
v

Vampire

11/21/2023, 10:10 AM
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.
👍 1
m

mbonnin

11/21/2023, 10:10 AM
The day we have remote CC then it'll be slower
1
(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)
v

Vampire

11/21/2023, 10:13 AM
Ah, now I see what you mean. Yeah, you can also not reuse the CI CC locally then.
nod 1
n

Nick Kleban

11/21/2023, 10:14 AM
Thank you guys for the insights!
💙 1