Evgeny Chugunnyy (John)

Currently our tests are slow not because of Artipie docker image. `artipie/artpie` image is fine. Main culprit is preparation of client or extra working containers. Those are based on clean...

Actually, testcontainers may have some caching features, this is to be investigated too.

Also, when actively debugging/running tests some may start to fail in package downloading, probably due to very frequent http requests to the same files in the repos. Yet another reason...

Currently, local docker client image caching is supported in: conda, PyPy, rpm and debian S3 integration test cases in artipie-main and adapters. And on `conan-adapter` for regular integration tests.

Currently Integration Tests run about one hour. Below are maven results from logs for `-Pitcase` for artipie: ``` 2024-02-28T10:29:54.5017318Z [INFO] build-tools ........................................ SUCCESS [ 0.538 s] 2024-02-28T10:29:54.5018394Z [INFO] artipie ...............................................

My current prospect on tests optimization: 1. Use single integration test client image per test(adapter) type, whenever possible. I've noticed that minor differences there take actually lots of extra time...

Parallel integration tests may provide extra 1.5x speed-up, but requires a lot of refactoring to be stable, so it’s not viable. Previous docker caching optimisation already provided 2x speed-up (60min...