Repository navigation
test(spring-boot): [Sample Tests 41] Drop Spring Boot 2.4 to 2.6 from the test matrix - #6381
Draft
runningcode wants to merge 25 commits into
Draft
runningcode wants to merge 25 commits into
runningcode wants to merge 25 commits into
Conversation
… module Adds the agent setup to sentry-spring-boot-4: an agentFixture app that runs in a child JVM with the built agent attached, and the integrationTestOtelAgent suite with its integrationTestOtelAgentWithoutAutoInit task. The sample's tests were the same as the Boot 3 agent sample's, so the fixture and tests are the Boot 3 ones with Boot 4's packages and starters. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix, which now runs both agent tasks and no longer builds the agent separately. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… module Adds the agent setup to sentry-spring-boot, as in the Boot 3 and 4 modules. The sample's tests were the Boot 3 agent sample's minus Cache and RestClient, which Boot 2 doesn't have. GraphQL and Kafka are gated on Boot 2.7, as in the other Boot 2 suites. The shared app has to start on Boot versions without Kafka support, so the Kafka test starts an app of its own with the kafka profile and an in-JVM broker. AgentApp becomes a class for that, with the shared instance in its companion. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix, which now runs both agent tasks and no longer builds the agent separately. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…oot 2 agent Ports the tracing and GraphQL checks to the Boot 2 agent suite, and gives the app three minutes to start, as for Boot 3 and 4. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adds an integrationTest suite to sentry-spring-jakarta that runs a plain Spring MVC app, set up by an AbstractAnnotationConfigDispatcherServletInitializer as in a WAR, in an embedded Tomcat against MockSentryServer. Tomcat runs every servlet container initializer the classpath registers, as it does for a WAR, and Spring Boot stays off the classpath, so Sentry's initializer adds SentrySpringFilter the way it does in a real deployment. The suite ports the sample's Person and Metrics tests and also checks that the error carries its request. The profiler rejects a traces path with a dot anywhere in its absolute form, so the suite puts it in the temp dir. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix. That was the matrix's last runner step, so it drops the Python setup and the runner's logs too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adds sentry-spring-jakarta's embedded-Tomcat integrationTest suite to sentry-spring-7, with the module's packages. The sample's tests were the jakarta WAR sample's, so the suite is too. Spring Boot 4's BOM picks Spring 7 and Tomcat 11. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix. That was the matrix's last runner step, so it drops the Python setup and the runner's logs too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adds sentry-spring-jakarta's embedded-Tomcat integrationTest suite to sentry-spring, with the module's packages and javax.servlet. The sample's tests were the jakarta WAR sample's, so the suite is too. Spring Boot 2's BOM picks Spring 5.3 and Tomcat 9. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix. That was the matrix's last runner step, so it drops the Python setup, the runner's logs and the exclude properties only the samples and the runner read. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adds SentryAppenderIntegrationTest, which configures the Sentry appender from XML in a logger context of its own and checks what reaches MockSentryServer: the warning event with its context tag and flag, the error with its exception and breadcrumbs, and the logs with their attributes. Logs are enabled through external configuration, as the sample's sentry.properties does, because the appender has no attribute for them. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adds SentryHandlerIntegrationTest, which configures the Sentry handler through a logging properties file read by LogManager, as the sample does, and checks what reaches MockSentryServer: the warning with its flag, the error with its exception and breadcrumbs, and the logs with their attributes. Its logger is outside io.sentry, whose loggers the handler drops, and the test restores the LogManager configuration the other tests read. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…nsport SentryEndToEndTest reports through the APIs an app uses without integrations and checks what reaches MockSentryServer: messages at the scope's and an explicit level, an exception with its feature flag, an event with a fingerprint, breadcrumbs from an event processor and a beforeBreadcrumb callback, ten events in a row, a transaction with a child span, and metrics with the scope's attributes. It ports the core part of the console sample's system test, which ran the sample's JAR against the Python mock server. The sample's profiling and Kafka parts follow in their own modules. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…n type end to end The console sample's test checked that the captured exception arrives with its type, RuntimeException, not just its value. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…d before exiting The console samples' system tests ran each sample in its own JVM, asserted that it exited with 0 within 30 seconds, and relied on the shutdown hook to send everything, because the samples never flush or close Sentry. The in-process end-to-end tests flush explicitly, so neither the clean exit nor the hook's flush was tested any more. Run a small app in a child JVM that returns from main without flushing, and check that it exits with 0 and that its event, log and metric arrive. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ContinuousProfilerEndToEndTest starts a sampled transaction with the TRACE profile lifecycle and checks that its profile chunk reaches MockSentryServer, linked to the transaction by the profiler ID. It ports the profiling part of the console sample's system test. The profiler rejects a traces path with a dot anywhere in its absolute form, so the test puts it in the temp dir. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
SentryKafkaEndToEndTest publishes a message through a wrapped KafkaProducer to an in-JVM KRaft broker, consumes it with SentryKafkaConsumerTracing, and checks what reaches MockSentryServer: the queue.publish span in the producing transaction, and a queue.process transaction with the consumer origin and the Kafka system that continues the producer's trace. It ports the Kafka part of the console sample's system test, which needed a Redpanda container. The broker comes from spring-kafka-test 3, which needs Java 17, so the test classpaths resolve Java 17 variants. The tests run on it anyway. With its core, profiling and Kafka parts ported, the console sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the console OTLP sample. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…metry setup AgentlessEndToEndTest builds the OpenTelemetry SDK through its autoconfiguration, which loads Sentry's customizer, and checks what reaches MockSentryServer: events, a transaction traced through OpenTelemetry with its child span and profile, and metrics. It ports sentry-samples-console-opentelemetry-noagent's system test, which no CI job ran. The customizer only initializes Sentry when the environment asks it to, so the test task sets SENTRY_AUTO_INIT. These are the module's first tests, so it applies the Kotlin plugin and gets an API dump. The sample has no system test left, so it comes off the system-test runner and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…n type in agentless mode Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
OtlpEndToEndTest captures a message, a log and a metric inside an OpenTelemetry span with OpenTelemetryOtlpEventProcessor installed, and checks what reaches MockSentryServer: the event carries the span's trace and span IDs, and the log and the metric arrive. It ports the OTLP-specific part of the console OTLP sample's system test, which never checked the link. The sample's other assertions are the console sample's, which SentryEndToEndTest covers. The sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the Spring Boot 4 OTLP sample, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Adds an integrationTestOtlp suite to sentry-spring-boot-4: the servlet app with the OpenTelemetry Spring Boot starter, set up by sentry-opentelemetry-otlp-spring, and OpenTelemetryOtlpEventProcessor. It ports the sample's tests, which were the servlet suite's without OkHttp, and keeps the log and metric attribute checks the sample had dropped. The sample's transactions came from Sentry's own tracing, which CI enabled with SENTRY_TRACES_SAMPLE_RATE, so the suite sets the sample rate the same way. A new test checks what OTLP mode is for: an error in a request carries the request's OpenTelemetry trace. Events point at that trace rather than at Sentry's transaction, so the GraphQL errors are checked next to their transactions instead of by trace ID, as the sample did. The sample has no system tests left, so it comes off the system-test runner. It was the backend workflow's last sample, so the workflow goes too. The Spring Boot 4 matrix runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…oot 4 OTLP suite Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every sample's system test now lives in the module it tests, so the Python runner, its mock Sentry server, requirements.txt and the Makefile targets that ran them have nothing left to run. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…upport With the runner gone, nothing applies the io.sentry.systemtest convention plugin or depends on sentry-system-test-support, which held the HTTP and GraphQL clients and the TestHelper the system tests used. The envelope matchers it delegated to stay in sentry-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ests The e2e_tests rule now covers MockSentryServer, where each kind of end-to-end test lives, the Spring suites per flavor, the OpenTelemetry agent fixture, how to run them and the gotchas the migration found. The test skill runs integration suites by their source set instead of the Python runner, the new_module rule no longer asks for sample tests, and AGENTS.md drops sentry-system-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…client and log4j2 suite The context's TestRestTemplate adds trace headers of its own whenever Sentry customizes the RestTemplateBuilder, not only in OpenTelemetry mode, and the Spring Boot modules have an integrationTestLog4j2 suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Spring Boot 2.4 to 2.6 are long past end of life. They were the only reason the Boot 2 suites left GraphQL and Kafka out of their compilation below 2.7, which stands in the way of compiling the suites once and running them on each Boot version's classpath (JAVA-802). The Kafka beans stay in a profile, so only the Kafka tests need a broker. Co-Authored-By: Claude <noreply@anthropic.com>
This was referenced Oct 26, 2026
Merged
This was referenced Oct 26, 2026
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Draft
📲 Install BuildsAndroid
|
Base automatically changed from
no/integration-test-docs
to
no/remove-system-test-support
October 27, 2026 08:05
Base automatically changed from
no/remove-system-test-support
to
no/remove-system-test-runner
October 27, 2026 08:05
Base automatically changed from
no/remove-system-test-runner
to
no/boot4-otlp-integration-test
October 27, 2026 08:06
Base automatically changed from
no/boot4-otlp-integration-test
to
no/otlp-integration-test
October 27, 2026 08:06
Base automatically changed from
no/otlp-integration-test
to
no/otel-agentless-integration-test
October 27, 2026 08:06
Base automatically changed from
no/otel-agentless-integration-test
to
no/kafka-integration-test
October 27, 2026 08:06
Base automatically changed from
no/kafka-integration-test
to
no/core-integration-test
October 27, 2026 08:07
Base automatically changed from
no/core-integration-test
to
no/jul-integration-test
October 27, 2026 08:07
Base automatically changed from
no/jul-integration-test
to
no/log4j2-integration-test
October 27, 2026 08:07
Base automatically changed from
no/log4j2-integration-test
to
no/spring-integration-test
October 27, 2026 08:07
Base automatically changed from
no/spring-integration-test
to
no/spring-7-integration-test
October 27, 2026 08:13
Base automatically changed from
no/spring-7-integration-test
to
no/spring-jakarta-integration-test
October 27, 2026 08:13
Base automatically changed from
no/spring-jakarta-integration-test
to
no/boot2-otel-agent-integration-test
October 27, 2026 08:14
Base automatically changed from
no/boot2-otel-agent-integration-test
to
no/boot4-otel-agent-integration-test
October 27, 2026 08:14
runningcode
force-pushed
the
no/boot4-otel-agent-integration-test
branch
from
October 27, 2026 08:20
43d301d to
7ce9f6d
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Stack (Sample Tests)
main)📜 Description
Drops Spring Boot 2.4.13, 2.5.15 and 2.6.15 from the Spring Boot 2 matrix, which now tests 2.7.0 and 2.7.18.
bootSupportsGraphqlAndKafka, the conditional dependencies and the compile excludes are gone.💡 Motivation and Context
Part of JAVA-802 (#6379). Spring Boot 2.4 to 2.6 are long past end of life. They were the only reason for the gating, which would stand in the way of compiling the suites once and running them on each version's classpath in the next PR.
💚 How did you test it?
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
#6382 moves the matrix to a Gradle task per version.
#skip-changelog
🤖 Generated with Claude Code