This message was deleted.
# performance
s
This message was deleted.
e
Thanks!
👍 1
g
In case you’re benchmarking a scenario with configuration cache enabled, be aware that reading some of these these properties on each build will cause a cache miss since they always change e.g. “build number” (scenario name is OK)
e
@Gabriel Feo we're not using configuration cache yet. But, if I just read the property via
System.properties['org.gradle.profiler.number']
and pass it in a build scan tag, will it change the configuration cache input?
g
Yes, because if you read it Gradle understands that the configuration of your build varies according to that variable. It becomes an input to the configuration. So whenever it changes Gradle decides it cannot use the cached configuration because it relied on ‘profiler.number == 2’ which it is now ‘== 3’
It’s detected as configuration input when you call
System.properties.get
or
System.getenv
, not to do with the build scan API
To me the build number was unnecessary in the end. To filter in GE for a benchmark run I basically • send only scenario name • send some other value to identify a ‘benchmark run’. In my case the CI job ID • Ensure warmups don’t send scans, only iterations
👍 1