📜 Description

Removes outputs.upToDateWhen { false } from the systemTest tasks in the sentry-samples/* modules and replaces it with proper Gradle input tracking via a new io.sentry.systemtest convention plugin.

The system tests launch the packaged sample app (shadowJar/bootJar/war) from build/libs as a separate process — it is not on the test classpath. With only outputs.upToDateWhen { false } removed, Gradle would compute up-to-date purely from the test classes and runtime classpath, so a separate jar build could refresh the artifact while systemTest was skipped, meaning the assertions never ran against the rebuilt sample.

Rather than repeat the wiring in all 22 sample build files, it lives in one build-logic convention plugin (build-logic/src/main/kotlin/io.sentry.systemtest.gradle.kts), following the existing io.sentry.spotless / io.sentry.javadoc pattern. Each sample applies id("io.sentry.systemtest"). The plugin auto-detects the packaging task with precedence war → shadowJar → bootJar (mirroring test/system-test-runner.py) and declares its archive as a systemTest input:

tasks.matching { it.name == "systemTest" }.configureEach {
  val archiveTask =
    listOf("war", "shadowJar", "bootJar").firstOrNull { it in tasks.names }
      ?: throw GradleException("…none of war/shadowJar/bootJar exist…")
  // Declaring the archive as an input also wires the dependency on its producing task.
  inputs.files(tasks.named(archiveTask))
    .withPropertyName("appArchive")
    .withNormalizer(ClasspathNormalizer::class.java)
  …
}

OpenTelemetry agent. The agent-based OTel samples are also launched with -javaagent:<sentry-opentelemetry-agent>, started outside the test JVM and likewise untracked. The plugin exposes a usesOpenTelemetryAgent opt-in (sentrySystemTest { usesOpenTelemetryAgent = true }); the three agent samples enable it and the agent jar is tracked as a content input. The runner already builds and launches the agent before invoking the task, so it is tracked by path (no cross-project task dependency), which keeps it configuration-on-demand and configuration-cache compatible.

Notes on Gradle best practices:

• tasks.matching { … }.configureEach + it in tasks.names + tasks.named(…) are all lazy — no eager task realization (configuration avoidance preserved).
• No afterEvaluate.
• Misconfiguration fails loudly (GradleException) rather than silently skipping the input.
• Configuration cache verified: entry stored then reused across runs with no problems.

💡 Motivation and Context

outputs.upToDateWhen { false } disabled up-to-date checks and build-cache reuse for the systemTest tasks because the launched JAR/WAR (and OTel agent) were not modeled as task inputs. This models those inputs properly — in one place — instead of disabling incremental builds wholesale.

💚 How did you test it?

• ./gradlew spotlessApply / spotlessCheck pass; the convention plugin compiles and applies.
• ./gradlew --dry-run --configuration-cache :sentry-samples:<module>:systemTest for a console (shadowJar), Spring Boot 2 (shadowJar), Spring Boot 4 (bootJar), and Tomcat (war) module confirms the packaging task is wired ahead of systemTest; agent modules additionally track the agent jar. Configuration cache stores and reuses cleanly.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

#skip-changelog