Should Quarkus Gradle plugin avoid resolving effective config during configuration?

[cdsap]

Some of the Quarkus Gradle plugin tasks in this repository are configuration-cache compatible, and we are seeing cache hits for tasks like quarkusBuild. However, we have noticed that the configuration cache is invalidated when unrelated system properties change, even when those properties do not affect the Quarkus build (issue #52464).
In other words, the task outcomes do not change because these system properties are not actual inputs to the build, but the mere fact that they are read during configuration causes configuration-cache misses. Ideally, we should avoid reading system properties during configuration, and instead read them during task execution. If some system properties are actually influential, we should explicitly model them as inputs (similar to what we do for environment variables and Quarkus properties).

Where the system properties are being read
The first thing to understand is who is resolving the system properties that trigger invalidation. After some investigation, we observed this happens when instantiating SmallRyeConfigBuilder in ConfigUtils. During builder initialization, we call addDefaultSources() from SmallRye, and that’s where system properties are read:

protected List<ConfigSource> getDefaultSources() {
  List<ConfigSource> defaultSources = new ArrayList();
  defaultSources.addAll(this.getSystemSources());
  defaultSources.addAll(this.getPropertiesSources());
  return defaultSources;
}

This SmallRyeConfigBuilder is used to instantiate the effective configuration in the Quarkus Gradle plugin. Now that we know when the system-property read occurs, the remaining question is where in the plugin we are referencing configuration during Gradle configuration time.

Places where we found configuration-time reads
So far, we have identified the following locations:

1. QuarkusBuild: This task defines an @InputFiles property, getBuildInputFiles, which represents the “codegen output files” inputs for QuarkusBuild. The problem is that these inputs are currently computed during configuration and depend on general/package settings from the Quarkus extension. When we made this task configuration-cache compatible, we had to remove direct extension references and instead define explicit inputs, but some paths still trigger config resolution early. Also this fact could be related to issues like 9400d90
2. Task configuration blocks (QuarkusGenerateCode, QuarkusBuild, etc.) Some configuration blocks call methods that resolve the effective config to compute values, which triggers system property reads during configuration. This is caused the previous point.
3. QuarkusExtensionView: Reading values like ignoreEntries from the extension inside the constructor forces a new instantiation of the build config, which again triggers effective config creation.

Potential solutions

1. Ignore system properties in config resolution: In theory, Quarkus Gradle configuration could define a set of system properties to ignore. However, this behavior is inside SmallRye (SysPropConfigSource), so unless we can influence that source behavior, this seems unavoidable once we instantiate the effective configuration
2. Remove configuration-time BaseConfig/effective-config calls in the problematic paths
   This would mean restructuring those parts of the plugin so that effective config is only instantiated during execution, and any required values are either:

• read lazily during execution, or
• modeled explicitly as task inputs

If we proceed with option 2, we will likely need to redefine QuarkusBuild#getBuildInputFiles. This code is old, but it is critical because it directly affects the task inputs of the Quarkus build. I think this needs an open discussion before changing it.

Side note

Because these configuration-cache misses are impacting us, I prepared a PR that introduces an experimental mode which disables using BuildConfig during configuration time. This allows full configuration-cache compatibility in cases where the cache would otherwise miss due to unrelated system property changes.