-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI for building and releasing images #2
Comments
@LanderU: use https://github.com/ros-realtime/linux-real-time-kernel-builder as a reference to do the release |
Hello. I just wanted to add my input in regards of:
I have a project (that needs love) that was producing daily releases of more than 2GB by splitting the images in smaller files. I used lzma as compression as it had a decent tradeoff between time compressing and size. Example: https://github.com/awesomebytes/ros_overlay_on_gentoo_prefix/releases So I think it should be fine. No one ever complained about it from Github. |
Interesting and clever idea. Not sure if is needed for the time being because our image is under 2GB. If we want to release desktop images, it'll be above 2GB. However, having a splitted file is not exactly beginner friendly either. Given that installing |
Providing instructions on how to install desktop may be enough I think :) at least for the time being |
The build process takes about 10-15 minutes on CI without compressing the image. The resulting image is then 8GB, which very large. Github releases have a 2GB/file limit, so we should go under that. When I tried to
xz
the image, If I recall, I got it to about 1.7GB, which would be below that limit if I'm not wrong. In that case, we can post these images directly to Github releases (only for tags tho). Not sure how Github will feel once we start building more images tho.That said, the
xz
process takes up at least 15 minutes on CI without including the build process, as GH's CI runner is only 2 cores when I checked. This means a build would be more than 30 minutes. GH CI only offers 2000 minutes/month, which means <100 builds/month. This might be good enough, especially if the build is limited to tags ans master branch only (depends on the number of images)? Although I suspect this repository will experience more burst of activities, which might be annoying to deal with. Still we might be able to start here for now.One idea is to have a self-hosted runner running somewhere. This will allow unlimited time. I might be able to set something up on my home server if we don't abuse it... Coupled with the 2GB/file limit, it might be an okay solution.
The text was updated successfully, but these errors were encountered: