Introduce a mechanism to obtain the build result when using configuration caching

[cesar1000]

Expected Behavior

I'd like to have the ability to acquire the build result from within my build when configuration caching is enabled. In particular, I'd like for build services to be able to acquire the build result at the time the build finishes (e.g. through a new interface, like Closeable, or a new finish event in OperationCompletionListener).

Current Behavior

Before configuration caching, builds would be able to add a BuildListener to the Gradle object to obtain the build's BuildResult. Configuration caching doesn't allow the use of build listeners, which makes it impossible to acquire build results.

Context

We have an error reporting plugin that monitors our builds for errors, presents a summary at the end of the build, and posts the error summary to our code review tool. After updating it for configuration caching, we've lost the ability to detect failures that happen outside of any tests – like compilation issues, failures during configuration, or failures to store the configuration cache. We haven't found and viable alternative.

[soloturn]

is this related so the build does not show a summary of the test cases executed any more ?

tasks.test {
  useJUnitPlatform()
  testLogging.showStandardStreams = true
  afterSuite(
    KotlinClosure2<TestDescriptor, TestResult, Unit>(
      { descriptor, result ->
        if (descriptor.parent == null) {
          logger.lifecycle("Tests run: ${result.testCount}, Failures: ${result.failedTestCount}, Skipped: ${result.skippedTestCount}")
        }
        Unit
      })
  )
}

[eskatos]

Related issue on the Kotlin Gradle Plugin side

• KT-53442 - Rework KotlinBuildStatsService to work properly with configuration cache

[jonnycaley]

I wrote an article that uses build services to capture build information as an alternative to BuildListeners that you might find useful - https://proandroiddev.com/gradle-configuration-caching-replacing-a-build-listener-with-build-services-40bde11937f1

[bamboo]

Hi @cesar1000, this public specification describes how we're planning to improve the situation in 8.1.
Let us know what you think.

[cesar1000]

Thanks, @bamboo! I dropped a couple of questions in the doc.

[bamboo]

Implemented via:

• Introduce FlowScope API #23222
• Make ArchiveOperations, ExecOperations and FileSystemOperations available to flow actions #23252
• Allow flow actions to use build services registered in any order  #23260
• Rename FlowProviders.{requestedTasks => buildWork}Result #24187
• Isolate flow actions and ensure only them can reference the buildWorkResult provider #24206
• Ensure flow actions cannot depend on tasks (yet) #24245