aurae
aurae copied to clipboard
aurae-runtime
Create and use build container (speed up the builds)
Right now we have several build jobs that are executed during a pull request and a merge to main
Can we please leverage #78 and have the builds use a container instead of apt-get installing the dependencies each iteration?
I took a stab at this with https://github.com/sidpalas/aurae/pull/1
It still needs some work and the container-based version is slower than the one without. Does anyone have thoughts on why this is? Are containers run with constrained CPU/memory relative to the default VM?
The build step in the two jobs are doing different work (container one is downloading crates). That would account for the some difference in run times.
They both were cache hits (so not cold builds) but the container based one either didn't have everything it needed cached, or it isn't configured (or can't) take advantage of the cache as well as the other.
The biggest take away for me though was that initializing the container was more time then downloading the dependencies (the current setup). So it may be worth waiting to switch until containers can provide some other value or the dependencies increase, flipping the advantage.
@future-highway, that makes sense!
I added another test job using the busybox image (1.24MB) and it starts in 2 seconds to see how long initialization would take for a small image, so it seems that most of the container initialization time is spent pulling the large image with the Rust toolchain.
With self-hosted runners, this image could be cached across runs, but with GitHub's hosted runners I don't think we have any control over image caching.
Holding off until there is a significant speedup seems like the way to go.
Also, I am not very familiar with Rust so perhaps others have ideas on making the build container image smaller
@future-highway, that makes sense!
I added another test job using the busybox image (1.24MB) and it starts in 2 seconds to see how long initialization would take for a small image, so it seems that most of the container initialization time is spent pulling the large image with the Rust toolchain.
With self-hosted runners, this image could be cached across runs, but with GitHub's hosted runners I don't think we have any control over image caching.
Holding off until there is a significant speedup seems like the way to go.
Also, I am not very familiar with Rust so perhaps others have ideas on making the build container image smaller
You might be able to leverage this experimental GH actions cache
https://docs.docker.com/build/cache/backends/gha/
We have migrated the jobs to use a build container for both the final build step and the test jobs.
