Fix reports.register() failing with "Cannot call TaskOutputs.file() after task started execution"

[Copilot]

Using reports.register("xml") fails at runtime because the NamedDomainObjectFactory was calling outputs.file() lazily — the factory is only invoked when the container is first iterated, which happens inside buildArguments() during task execution, after Gradle has locked task outputs.

// Previously failed with:
// "Cannot call TaskOutputs.file(Object) on task ':spotbugsMain' after task has started execution"
tasks.spotbugsMain {
    reports {
        register("xml")
        register("html")
    }
}

Changes

• Remove outputs.file() from the factory — domain object creation no longer has any side-effects on task outputs, making register() safe at any point in the lifecycle.

• Re-register outputs lazily via reports.matching { } — replaces the removed call with a ConfigurableFileCollection backed by an anonymous Callable:

  • Uses (outputs as org.gradle.api.tasks.TaskOutputs) explicit cast — without it Kotlin resolves AbstractTask.getOutputs() to the internal TaskOutputsInternal, which violates the ArchUnit "no Gradle internal API" rule.
  • Uses reports.matching { } (Gradle's API) rather than reports.filter { } (Kotlin's Iterable.filter) — filter only iterates already-realized items and silently skips items registered with register(), causing those reports to be omitted from output tracking. matching realizes pending items on iteration.
  • Uses an anonymous Callable object rather than a lambda, following the existing NamedDomainObjectFactory pattern for configuration-cache serialization safety.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• dl.google.com
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.xml/javax.xml.namespace=ALL-UNNAMED -Xmx4g -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en -Duser.variant -cp /home/REDACTED/.gradle/wrapper/dists/gradle-8.14.4-bin/92wwslzcyst3phie3o264zltu/gradle-8.14.4/lib/gradle-daemon-main-8.14.4.jar (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[hazendaz]

@copilot See the ci builds results on this, they are failing for a different reason now. There are also a number of warnings that possibly are unrelated but might as well fix those if possible.

[hazendaz]

@copilot the build doesn't like commit message 'Changes before error encountered' as it does not follow proper convention, can you rebase and fix that to 'fix: ' prefix like others have?

[Copilot]

@copilot the build doesn't like commit message '[Changes before error encountered](02d1ca5...

I investigated the CI failures more carefully and found two issues:

1. Config-cache ConcurrentModificationException (the actual build failure): Gradle's configuration-cache serializer visits reports's internal pendingMap while the output Callable simultaneously tries to realize items from it. Fixed in 17cabe6 by adding reports.toList() in the reports(Action) method — this pre-realizes all lazily-registered items before the serializer ever visits the pending map.

2. Commit message 02d1ca5 "Changes before error encountered": I attempted a git rebase -i to fix this, but the push mechanism available to me (report_progress) doesn't support force push (required after history rewriting). When the push failed, report_progress fetched origin and rebased, which caused git to skip our fix commits as "already applied" (same patch content) — leaving the old bad commit still visible in the branch history.

To fix the commit message, you'll need to force-push manually:

git fetch origin copilot/check-issue-1539
git checkout copilot/check-issue-1539
git rebase -i HEAD~6  # mark 02d1ca5 as 'reword'
git push --force-with-lease origin copilot/check-issue-1539

Or use Squash and merge on GitHub, which will combine all commits under the PR title.