astefanutti commented on pull request #2392: URL: https://github.com/apache/camel-k/pull/2392#issuecomment-859371412
> Thanks @astefanutti for your feedback. I totally agree that ideally we should be able to run e2e tests with a local operator instead of everything putting into a cluster. And at the same time I understand it's not an easy task to re-architect the current e2e testing. > > In addition, to be honest I think it's still an important technique in general to use a maven mirror in the cluster to speed up integration builds for typical camel-k developers. Even though kits cache builds with the same set of dependencies it can still download the same common artifacts time and time again for different deployments. Is this an unpopular view? I hope I'm not missing some important technique that everyone else already knows. I agree this is a useful option, that can also be leveraged to upload custom JARs. Plus your solution is simple and non-intrusive 👍🏼. > With a bit of surprise, I found that applying mirroring to the current e2e set on CI doesn't gain any performance boost, but theoretically I still believe there should be a performance gain especially in the future when the number of e2e tests outgrows the overhead of introducing the nexus mirroring. And for e2e testing on CI, running a local operator is not an option so the mirroring technique might become still useful. GitHub Actions VMs are quite low-end, so I suspect performances are more CPU and memory bound, than network bound. With 2-core CPU and 7 GB of RAM memory, it's not surprising that running a Kubernetes cluster, installing operators, and running a test suite is that slow, no matter how much Maven dependencies downloading is improved. -- 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. For queries about this service, please contact Infrastructure at: [email protected]
