On Mon, Apr 28, 2025 at 08:49:13AM +0200, Patrick Steinhardt wrote: > On Sat, Apr 26, 2025 at 10:12:51PM +0800, shejialuo wrote: > > On Fri, Apr 25, 2025 at 08:20:25AM -0700, Junio C Hamano wrote: > > > shejialuo <shejialuo@xxxxxxxxx> writes: > > > > > > > I want to know whether we should use the "cache" mechanism of CI for > > > > these third-party softwares? I somehow feel strange that we would > > > > download these softwares in every CI. > > > > > > It also feels wasteful to me that the CI jobs need to do a full > > > install-dependencies.sh over and over, instead of running it once > > > (per platform type), dumping the state, and let all the other jobs > > > on the same platform type to restart from that state ;-). > > > > That's right. I'll investigate how to implement this. > > It would be nice if we could adapt the Linux-based jobs to use > pre-seeded Docker images. The idea would be that those images are only > built once and then used by later steps of the pipeline. In theory, this > could even be extended so that we only rebuild images as-needed when > something changes so that the images are reused for multiple pipelines. > I agree that it would be better if we provide pre-built container image. But there is only one problem, which platform we should upload to? I somehow know that github container registry is free for public repository. So, we may just push the image into github container registry. However, I am not a member of the Git organization. So, I need a help from ones who have the access. > Another big benefit would be that this results in a fully-reproducible > environment for developers that can in theory be uploaded to a container > registry. So if you see that something fails only with a specific job > image, you can now trivially fetch that image and try to reproduce the > issue in the exact same image as CI used. > That's right, we could easily set up the development environment to replicate the problem without setting up the environment in our own machine step by step. > Patrick Thanks, Jialuo
