nevzheng opened a new issue, #13900: URL: https://github.com/apache/gravitino/issues/13900
### What would you like to be improved? Integration and database tests spend much of their time starting, rebuilding and resetting Docker containers and databases. The core database test work (#13515) found large savings from doing less of that. The same patterns may apply to the rest of the build: - **Reuse instead of rebuild.** Share an expensive resource per test class (or per run) instead of creating it for every test, and give tests that truly need isolation an explicit opt-out. - **Reset only what changed.** Clean up only the state a test touched, with the cheapest operation that restores it (e.g. `DELETE` the rows of non-empty tables instead of `TRUNCATE` on every table). - **Treat test data as disposable.** Keep throwaway data in memory (`tmpfs`) and skip durability work such as fsync on test containers. - **Make lifetimes explicit.** Hold resources in JUnit `ExtensionContext.Store` scopes (per test, per class, per run) with a reset hook, instead of static singletons that live for the whole JVM. - **Allow injected dependencies.** Let tests use a service the environment provides (e.g. on Kubernetes) as well as Testcontainers. Caveat: these are starting hypotheses. The measured effect of each pattern on core is in the PRs that implement it (#13518, #13899). Other modules will differ, so measure before changing anything. ### How should we improve? A research spike, then targeted fixes: 1. **Audit.** For each CI job and module, record which containers start, how often, how long startup and per-test setup take, and the module's total time. 2. **Investigate.** Check each module against the patterns above. 3. **Triage.** Rank the findings by CI minutes saved against effort and risk. 4. **Remediate.** Make small PRs, one per finding. If several modules need the same thing, propose a shared lifetime model following `BackendTestExtension` in #13518. Related: #13515 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
