-
Notifications
You must be signed in to change notification settings - Fork 324
CI Visibility Gradle instrumentation #4894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI Visibility Gradle instrumentation #4894
Conversation
…k & test command calculation in Gradle build listener
… handled in different threads
…operty to disable build tracking
… only in the project, but also in the included builds
cfc8aab to
59700d4
Compare
…s stubbing of that particular class does not work on Java 9+
…rnal-api, since corresponding classes were moved
| Project rootProject = gradle.getRootProject(); | ||
| Collection<GradleUtils.TestFramework> testFrameworks = | ||
| GradleUtils.collectTestFrameworks(rootProject); | ||
| if (testFrameworks.size() == 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be good to report back when customers do have multiples, either with a debug log so we can get it in troubleshooting, or a telemetry log message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, added a log message
…henko/gradle-test-events-instrumentation
What Does This Do
Adds a new instrumentation for Gradle Daemon processes.
The instrumentation creates spans for entire build and for each Test task within a build.
The instrumentation passes IDs of created spans to forked test processes (so that the spans created in those processes could refer to the spans from the parent daemon process).
Motivation
This is needed in order to support Test Session and Test Module levels visibility (a CI Visibility feature) for Gradle builds.
"Test session" is a CI Visibility term that is equivalent to tests run for a single project, "Test module" is equivalent to tests run for a single module within a project.
Additional Notes
Gradle Daemon is supposed to be a long-lived process potentially reused for multiple builds.
Since multiple builds for different projects can be executed by the same daemon, repository root cannot be calculated during the agent's init phase and stored in a static field anymore.
Instead it is now a part of
TestDecoratorstate (the decorator lifetime can now vary depending on whether it is used with a Gradle build or a forked test process run).Some CI Visibility classes had to be moved from
dd-java-agent/agent-ci-visibilitymodule tointernal-apimodule in order to accommodate this change.