On Fri, Jan 03, 2025 at 03:46:41PM +0100, Patrick Steinhardt wrote: > We have split the CI jobs in GitHub Workflows into two categories: > > - Those running on a machine pool directly. > > - Those running in a container on the machine pool. > > The latter is more flexible because it allows us to freely pick whatever > container image we want to use for a specific job, while the former only > allows us to pick from a handful of different distros. The containerized > jobs shouldn't cause a significant slowdown, either, so they do not have > any significant upside to the best of my knowlegde. The only upside that > they did have before the preceding commit is that they run as a non-root > user, but that has been addressed now. I remember running into a few issues recently with containerized jobs, so I dug in the archive a bit. The issue there was that the container was not equipped to support the dynamically-linked version of node that was being mounted into place (whereas the runner image from the CI provider would work fine). I guess that's probably not a big deal for us here. These are roughly the same environments, just pulling from docker instead of relying on the runner images. It's possible that Actions scripts might depend on something special in the runner image, but in practice I think they try to keep the dependencies pretty light. So we're probably OK to proceed here, and deal with any problems in the unlikely event that they come up. I do wonder if it will affect run times. Presumably GitHub has made it pretty fast to get things started on the bare runner image. Now we're pulling docker images. That is hopefully pretty optimized and cached, but it is extra work. Might be worth measuring. -Peff
