How should I fix this problem with the configurati...
# configuration-cache
j
How should I fix this problem with the configuration cache in a settings plugin? It is related to the function
onlyIf
in the new develocity plugin
Copy code
WARNING: Error invoking build scan publishingCondition action
        Parameter specified as non-null is null: method com.javiersc.hubdle.settings.HubdleSettingsPluginKt.getHubdleSettings, parameter <this>
The relevant code is:
Copy code
public val publishAlways: Property<Boolean> =
    objects.property<Boolean>().convention(System.getenv("CI") == "true")
Copy code
private fun Settings.configureGradleDevelocity() {
    pluginManager.apply("com.gradle.develocity")
    
    configure<DevelocityConfiguration> {
        buildScan { scan ->
            scan.publishing.onlyIf { hubdleSettings.buildScan.publishAlways.get() }
        }
    }
}
m
The infamous "name punning" may help, though I'm surprised you hadn't hit any serialization problems:
Copy code
private fun Settings.configureGradleDevelocity() {
    pluginManager.apply("com.gradle.develocity")
    
    val publishAlways = hubdleSettings.buildScan.publishAlways
    configure<DevelocityConfiguration> {
        buildScan { scan ->
            scan.publishing.onlyIf { publishAlways.get() }
        }
    }
}
Can you please prepare a minimal reproducer for us to investigate further?
on an unrelated note,
convention(System.getenv("CI") == "true")
might work better as
convention(providers.environmentVariable("CI").map { it == "true"}.orElse(false))
, by avoiding making the environment variable an input to configuration.
j
I am facing another issue now, I will try it when I fix the current one which is blocking me to test that, sorry and thank you!
> on an unrelated note,
convention(System.getenv("CI") == "true")
might work better as
convention(providers.environmentVariable("CI").map { it == "true"}.orElse(false))
, by avoiding making the environment variable an input to configuration.` There is no con about this?
m
There is no con about this? (edited)
Well, CC has to store the whole provider chain to re-evaluate it upon loading, but the overhead is likely tiny, unless you have thousands of these properties laying around.
👍 1
thank you 1
j
your workaround work 🙂 Do you still need a repro?
m
I suppose, what you're seeing is another consequence of
problems=warn
, in which case there's no need for the reproducer. Thank you for cooperation!
👍 1