Slim variant of nektos/act-environments-ubuntu:18.04 #196
Comments
|
@aidansteele I'm totally onboard with this idea 🚀 |
|
btw - here's the repo for the image i built: https://github.com/nektos/act-environments |
cplee
added
area/runner
|
Great, good to hear you think it's a reasonable idea. I'll try report back with my findings / PR in the next few days - week. |
|
I took the opposite approach by starting with act's default node:12.6-buster-slim image and adding what I need, which is currently docker. If you're interested in creating a slim image tailored to your use-case, feel free to fork https://github.com/phaze9/action-runner |
|
I got a chance today to start looking into this. I created a tool to convert the upstream The total size is now just under 50 GB 🤯 It looks like some new things have been added to the environment since @cplee's image was built. There are some steps I skipped as they failed and I didn't have time to look into why yet. The skipped steps were:
These were all the steps that resulted in a layer on disk greater than 50 MB.
|
|
Issue is stale and will be closed in 7 days unless there is new activity |
|
Issue is stale and will be closed in 7 days unless there is new activity |
@aidansteele @cplee what happened to this? I am not so familiar with using Docker images so would love it if you can point me to any docs on how to use this slim variant. I tried using |
|
I've found an interesting alternative approach. I'm using this as my base image: https://github.com/httptoolkit/act-build-base/blob/main/Dockerfile In effect, I'm sticking with a plain node base image, and just mixing in individual installers for the specific parts of the standard image I need, directly pulling individual scripts from Maybe there's a route through here? The installer scripts aren't quite as easy to use standalone right now as they could be (e.g. they don't work without document.sh preloaded into the right path) but with a few small tweaks there I can imagine an Act readme that said you can either:
For people like me, that'd be pretty useful - doing this seems to work perfectly, it's very easy, and it saves me an enormous amount of disk space. For GitHub themselves it makes sense to provide an actions base that includes the kitchen sink, but no individual devs need all of that locally for every build. |
My feeling reading some of the issues in this repo is that a lot of folks get stuck on the fact that we default to not using the enormous image - which is a reasonable IMHO. I've been thinking about whether there's a compromise we can reach, where we get e.g. 90% of the benefit at 30% of the size.
There would be pros and cons to this approach. Pros would likely be fewer issues on this repo, an easier getting-started process for most people, etc. Cons would be that the environment would be so close to the Github-provided one, but crucially not identical - which would cause a lot of head-scratching. Disregarding this for now, I started to take a cursory look at how we might want to shrink the image size.
All these numbers are on the uncompressed (~18GB total) image size:
What are your thoughts on this selective purge? I'm thinking that we'd likely want to automate the creation of the image + purging as well. If you're happy with the idea in general, I'll start experimenting with some approaches.
The text was updated successfully, but these errors were encountered: