Open bamboo opened 17 hours ago
Related to #31039
I suspect that some buildscan callback has a valuesource or build service reference and it kicks off the decoder. Then we race. Such callbacks may trigger failures even without deduplication/parallel store if they have project-resolving data captured. See this test, for example (quickly cooked from the build service test of the linked issue):
def "foobar"() {
settingsFile """
include("producer")
include("consumer")
"""
buildFile file("producer/build.gradle"), '''
apply plugin: 'base'
configurations {
'default' {
attributes {
attribute(Attribute.of('color', String), 'red')
}
}
}
artifacts {
'default' file('file.txt')
}
tasks.register('ok') {
doLast {
println("Making sure this project is considered relevant")
}
}
'''
file("producer/file.txt").createFile()
buildFile file("consumer/build.gradle"), """
apply plugin: 'base'
${withIdentityTransformSource()}
configurations {
implementation
}
def color = Attribute.of('color', String)
dependencies {
registerTransform(IdentityTransform) {
from.attribute(color, 'red')
to.attribute(color, 'blue')
}
implementation(project(":producer"))
}
abstract class ValueTask extends DefaultTask {
@TaskAction def doIt() {
println("value: " + System.properties["some.property"].get())
}
}
abstract class FilesValueSource implements ValueSource<String, Params> {
interface Params extends ValueSourceParameters {
ConfigurableFileCollection getInFiles()
}
String obtain() {
return "123"
}
}
def pp = providers.of(FilesValueSource) {
parameters {
inFiles.from(
configurations.implementation.incoming.artifactView {
attributes { attribute(color, 'blue') }
}.files
)
}
}
System.properties["some.property"] = pp
tasks.register('ok', ValueTask) {
dependsOn(configurations.implementation)
}
"""
when:
configurationCacheRun 'ok'
then:
outputContains 'Transforming file.txt'
outputContains "value: file.txt"
when:
configurationCacheRun 'ok'
then:
outputDoesNotContain 'Transforming file.txt'
outputContains "value: file.txt"
}
private String withIdentityTransformSource() {
"""
abstract class IdentityTransform implements ${TransformAction.name}<${TransformParameters.name}.None> {
@${InputArtifact.name} abstract Provider<FileSystemLocation> getInputArtifact()
@Override void transform(${TransformOutputs.name} outputs) {
println('Transforming ' + inputArtifact.get().asFile.name)
outputs.file(inputArtifact)
}
}
"""
}
Removing develocity plugin does seem to allow me to configure the project 3 out of 3 tries.
See this test, for example (quickly cooked from the build service test of the linked issue):
Hey @mlopatkin, I'm missing the connection to build scans from the test code you posted 🤔
See this test, for example (quickly cooked from the build service test of the linked issue):
Hey @mlopatkin, I'm missing the connection to build scans from the test code you posted 🤔
We do save build scan callbacks and the modified system properties in the build tree state before restoring the projects Thus, when something that requires a project to load is stored there, it breaks loading even without parallel/dedupe changes, like in 8.10 It also means that loading callbacks or the system property value may kick off background loading of shared objects if these data happen to be a shared object themselves.
I don't see how we can easily solve the original issue, but with some coordination we can ensure that the projects are ready by the time we start reading the stuff that references them.
I can pick this up if you'd like.
Initially reported in the androidx build:
The
ValueSource
in question is setup in DesugarLibUtils.kt#149 with parameters coming from a build service that resolves artifactFiles from a sharedConfiguration
.