feat: Implement compilation tracing for detailed build diagnostics#2845
feat: Implement compilation tracing for detailed build diagnostics#2845krrish175-byte wants to merge 5 commits intoscalacenter:mainfrom
Conversation
| cleanUpTasksToSpawnInBackground.toList | ||
| } | ||
|
|
||
| private def reportCompilationTrace( |
There was a problem hiding this comment.
Coukld we instead reuse the current tracing behaviour? Maybe an implementation of BraveTracer and dump the data there if the json file exists
| * Resource mappings allow files to be copied from source locations to custom | ||
| * target paths, similar to SBT's "mappings" field. | ||
| */ | ||
| object ResourceMapper { |
There was a problem hiding this comment.
This is not related to this PR
|
@tgodzik: Thanks for the review, I have refactored the implementation to address your points:
The changes are now pushed. Let me know if this aligns better with the design you had in mind! |
| if (properties.compilationTrace) { | ||
| val traceFile = bloop.io.AbsolutePath( | ||
| java.nio.file.Paths | ||
| .get(name.stripPrefix("compile ").stripSuffix(" (transitively)")) |
There was a problem hiding this comment.
Let's use some of the directories in 'bloop.io.Paths', we can mention which one user needs to create when bloop about is run
| NoopTracer | ||
| } | ||
|
|
||
| if (properties.compilationTrace) { |
There was a problem hiding this comment.
We should instead check if the trace files exists and if does, write to it. It's the same as with lsp.trace.json in metals
| val projectName = tags | ||
| .collectFirst { case ("compile.target", value) => value } | ||
| .getOrElse(name) | ||
| CompositeTracer( |
There was a problem hiding this comment.
Maybe we should either allow for the more complex Zipkin tracer or tracing using a file. Would make it a bit less complicated and we wouldn't need to add compositeTracer class
| import com.github.plokhotnyuk.jsoniter_scala.core.JsonValueCodec | ||
| import com.github.plokhotnyuk.jsoniter_scala.macros.JsonCodecMaker | ||
|
|
||
| case class CompilationTrace( |
There was a problem hiding this comment.
Do you have an example of how the trace file looks like?
| generatedClassFilePathsInDependentProjects: Map[String, File], | ||
| resources: List[AbsolutePath] | ||
| resources: List[AbsolutePath], | ||
| resourceMappings: List[(AbsolutePath, String)] |
There was a problem hiding this comment.
This looks like a change from a different PR
krrish175-byte
force-pushed
the
feature/compilation-trace
branch
from
6ed966f to
860919e
Compare
2 participants
Description
This PR introduces a new "compilation tracing" feature that records detailed information about every compilation run (successful, failed, or no-op) into a JSON file (
.bloop/compilation-trace.json). This allows users and tool authors to inspect exactly what happened during a build.This feature provides a structured, machine-readable record of these events, enabling better observability into the build process.
Key Changes
1. New Data Structures
CompilationTrace(and derived types likeTraceDiagnostic,TraceArtifacts) to model the structured trace data.compilationTraceboolean flag toTraceSettingsto enable/disable the feature at the workspace level.2. Trace Generation Logic
reportCompilationTracein CompileTask.scala. This method gathers results fromFinalCompileResult, structures them, and serializes them to JSON.3. Improved Failure Handling
PartialFailuretype discarded theSuccessfulCompileBundle(which holds the reporter and inputs). This resulted in traces for failed builds missing critical diagnostic information.PartialFailurein CompileResult.scala to optionally carry theSuccessfulCompileBundle.CompileResult.toFinalResultto expose this bundle inFinalNormalCompileResult, ensuring thatreportCompilationTracehas access to diagnostics even when compilation fails.4. Tests
Verification
Run the new test suite:
sbt "frontend/testOnly bloop.CompilationTraceSpec"Closing issue:
issue #2697
@tgodzik