improvement: reuse docker compose for e2e tests

[fangpenlin]

Description 📣

ref: https://linear.app/infisical/issue/PLATFRM-134/make-a-smarter-docker-compose-cache-system-to-avoid-recreating-compose

Tests 🛠️

The way you test this PR is mostly like the #91. The major difference is that now we have a cache system for the docker-compose. If we found a compose (multiple containers with a compose label) already meets the spec, we will not create a new one but reuse it instead. The purpose is to speed up development cycle.

To ensure this system works, you can run the only relay test case we have right now with TESTCONTAINERS_RYUK_DISABLED=true. This will stop the Ryuk container from cleaning up our compose containers. After successfully running the relay test case, you can then run again to see how long it takes and if it reuses the existing container.

After that, you can also set CLI_E2E_DISABLE_COMPOSE_CACHE=1 to disable the cache and you should see it boot the container from the ground up instead of using the cache.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
9387833	Triggered	Generic Password	22fcc91	e2e/packages/client/reset_db.go	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[greptile-apps]

Greptile Overview

Greptile Summary

This PR introduces a smart Docker Compose caching system to avoid recreating containers for E2E tests, along with new database and Redis reset utilities.

Key Changes

Container Reuse System (compose.go):

• Implements SHA1-based naming to identify identical compose configurations
• Checks for existing running containers and reuses them instead of recreating
• Introduces RunningCompose wrapper to handle pre-existing containers
• Refactors Stack API to directly manage compose lifecycle

Reset Utilities (reset_db.go, reset_redis.go, reset.go):

• New PostgreSQL reset function that truncates all tables while preserving migrations
• New Redis reset function using FlushAll
• Integration layer to reset both services via compose stack

Test Improvements (helpers_test.go):

• Added Reset() and ResetAndBootstrap() methods for test isolation
• Separated Bootstrap logic from Up for better reusability
• Cleaner API with direct Stack integration

Critical Security Issue

SQL Injection Vulnerability in reset_db.go (line 125): Table names from information_schema are directly interpolated into TRUNCATE statements without proper identifier escaping. While this is test code and the risk is lower, a malicious table name could execute arbitrary SQL. This must be fixed by using proper identifier quoting.

Other Issues Found

1. Context misuse in compose.go (line 48): Uses context.Background() instead of passed context
2. Panic usage: RunningCompose uses panic instead of returning errors
3. Race condition potential: Container state checking has TOCTOU window
4. Cleanup timing: t.Cleanup() registered after operations that could fail

Architecture Assessment

The caching approach is sound and will significantly speed up test execution by reusing containers. The reset mechanism properly isolates tests while avoiding the overhead of full container recreation. However, the SQL injection issue needs immediate attention before merging.

Confidence Score: 2/5

• This PR contains a critical SQL injection vulnerability that must be fixed before merging
• Score reflects the CRITICAL security issue in reset_db.go (SQL injection via unescaped table identifiers) plus the context misuse bug in compose.go. While this is test code and the architecture is sound, the SQL injection represents a significant security risk that prevents approval. The other issues (panic usage, race conditions, cleanup timing) are less critical but should also be addressed.
• e2e/packages/client/reset_db.go requires immediate attention for SQL injection fix (line 125). e2e/packages/infisical/compose.go needs context bug fix (line 48).

Important Files Changed

File Analysis

Filename	Score	Overview
e2e/packages/infisical/compose.go	3/5	Major refactor adding Docker container reuse logic with SHA1-based naming. Contains context misuse bug (line 48), potential race condition in container state checking, and panic usage instead of error returns. Core caching functionality appears sound.
e2e/packages/infisical/reset.go	4/5	New helper to reset Infisical services by calling client reset functions. Clean implementation with proper error handling and context propagation.
e2e/packages/client/reset_db.go	1/5	New database reset utility with CRITICAL SQL injection vulnerability (line 125) due to unescaped table identifiers. Also has potential conflict issues with hardcoded super_admin insertion. Requires immediate security fix.
e2e/packages/client/reset_redis.go	4/5	New Redis reset utility using FlushAll to clear all databases. Clean implementation with proper connection handling. FlushAll scope (all DBs vs single DB) should be clarified in comments.
e2e/relay/helpers_test.go	4/5	Refactored to use new Stack API and added Reset/ResetAndBootstrap methods. Cleanup registration timing could be improved but overall changes are sound and improve test isolation.

[greptile-apps]

_{7 files reviewed, 7 comments}

_{Edit Code Review Agent Settings | Greptile}

[akhilmhdh]

Small changes - doing an application testing

[maidul98]

tested and works as expected. the strategy makes sense to me