-
-
Notifications
You must be signed in to change notification settings - Fork 0
fix: flaky CI tests: singleton Testcontainers with reuse strategy #79
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
fix: flaky CI tests: singleton Testcontainers with reuse strategy #79
Conversation
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the Comment |
- Create TestcontainersManager singleton for shared container lifecycle - Update InfrastructureTestContainers to use singleton containers - Remove redundant startInfrastructure() calls from test setUp methods - Add testcontainers.properties for container reuse - Configure test task for parallel execution and proper timeouts - Update GitHub Actions workflow with Testcontainers support - Add comprehensive documentation in test resources README.md - Temporarily remove AZUL vendor requirement to allow any JDK 21 Co-authored-by: yacosta738 <[email protected]>
…n acquisition - Restore original AZUL Zulu JDK vendor requirement - Add retry logic with 3 attempts and 1s delays for token acquisition in ControllerIntegrationTest - Handles Keycloak timing issues during parallel test execution Co-authored-by: yacosta738 <[email protected]>
…c-4de5-bc47-4ebff83d5dd6
Test Results129 files ±0 129 suites ±0 1m 17s ⏱️ +23s For more details on these failures, see this check. Results for commit 98d06db. ± Comparison against base commit 754583a. This pull request removes 4 and adds 4 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
Qodana for JVM61 new problems were found
☁️ View the detailed Qodana report Contact Qodana teamContact us at [email protected]
|
|
@copilot CreateDefaultWorkspaceOnUserCreationIntegrationTest > should not create workspace when user already has existing workspaces() FAILED CreateDefaultWorkspaceOnUserCreationIntegrationTest > should create default workspace with firstname only when lastname is null() FAILED CreateDefaultWorkspaceOnUserCreationIntegrationTest > should handle workspace names with special characters and whitespace correctly() FAILED CreateDefaultWorkspaceOnUserCreationIntegrationTest > should create default workspace with 'My Workspace' when both names are null() FAILED |
I can see the ApplicationContext is failing to load for this test. This suggests the TestcontainersManager singleton isn't initializing containers properly before the Spring context starts. I'm investigating the root cause - it's likely related to the timing of when containers are accessed in the @DynamicPropertySource method. Will fix this shortly. |
- Wrap container initialization in try-catch blocks with detailed error messages - Add error handling to startAll() method for better diagnostics - Improves troubleshooting when containers fail to start in CI - Related to comment #3480851684 - investigating ApplicationContext failure Co-authored-by: yacosta738 <[email protected]>
- Removed @testcontainers annotation from InfrastructureTestContainers - We manage container lifecycle manually via TestcontainersManager singleton - @testcontainers extension expects @container fields which we don't use - This may resolve ApplicationContext initialization issues in CI Co-authored-by: yacosta738 <[email protected]>
Fix flaky CI tests using Testcontainers (PostgreSQL & Keycloak reuse strategy)
✅ Completed Items
🔍 Addressing ApplicationContext Failure
Investigation of comment #3480851684:
Root Cause Analysis:
The
@TestcontainersJUnit 5 extension was applied toInfrastructureTestContainersbut we're using a singleton pattern with manual lifecycle management. The extension expects@Containerannotated fields which we don't have.Changes Made:
@Testcontainersannotation - we manage lifecycle viaTestcontainersManagerstartAll()error handling for better diagnosticsWhy This Helps:
The singleton pattern with lazy initialization is still intact and working correctly.
Original prompt
Note
Custom agent used: Elite Backend Engineer - Kotlin & Spring Boot Specialist
Expert backend engineer delivering production-grade APIs and systems with Kotlin, Spring Boot 3, and reactive programming. Specializes in clean architecture, microservices, and high-performance, scalable solutions.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.