Editor Lite image

[erlioniel]

Description
Some time ago I've started to investigate can the image be smaller. I've managed to reduce image size three times (from 3 GB to 1 GB). The reasoning behind my research was that the private GitHub repo has a limited amount of action execution minutes. And seems like downloading the docker image is a significant part of the run tests action. By decreasing the size of the image, we reduced the time of the unity-test-runner from 5.0 mins to 2.3 mins.

But since I'm not interested in fighting around pull requests to this repo and do not have time to test all the limitations & edge cases I want just to share with you the dockerfile to let the community decide is it feasible to take some of my findings and cut them out from the official image.

Dockerfile:

ARG baseImage=unityci/base:latest
ARG editorImage=unityci/editor:2020.2.1f1-base-0

FROM $editorImage as builder

# Templates
RUN echo 'Cleaning image' \
# Remove templates
    && rm -rf /opt/unity/Editor/Data/Resources/PackageManager/ProjectTemplates/ \
    && rm -rf /opt/unity/Editor/Data/Resources/PackageManager/PackageTemplates/ \
# Remove everything except manifest from packages
    && find /opt/unity/Editor/Data/Resources/PackageManager/Editor/ \
          ! -name 'manifest.json' \
          -type f -exec rm -f {} + \
# Remove unnecessary Mono resources
    && rm -rf /opt/unity/Editor/Data/MonoBleedingEdge/lib/mono/monodoc/ \
    && rm -rf /opt/unity/Editor/Data/MonoBleedingEdge/bin-linux32 \
# SDK is not required for .NET Core
    && rm -rf /opt/unity/Editor/Data/NetCore/Sdk-* \
# We are not planning to debug in CI
    && rm -rf /opt/unity/Editor/Unity_s.debug \
# Remove playback engines
    && rm -rf /opt/unity/Editor/Data/PlaybackEngines/

###########################
#          Editor         #
###########################

FROM $baseImage

# Always put "Editor" and "modules.json" directly in $UNITY_PATH
ARG UNITY_PATH=/opt/unity
COPY --from=builder "$UNITY_PATH/" "$UNITY_PATH/"

# Alias to "unity-editor" with default params
RUN echo '#!/bin/bash\nxvfb-run -ae /dev/stdout "$UNITY_PATH/Editor/Unity" -batchmode "$@"' > /usr/bin/unity-editor \
 && chmod +x /usr/bin/unity-editor

[GabLeRoux]

Thanks for sharing your findings 🎉

do not have time to test all the limitations & edge cases

Indeed, that is also why it might be hard to accept a pull request removing things from images that are widely used as this could lead to a storm of support questions here and on discord. Most of us are working on our free time on this project, but we are definitely open to optimize the images with proper testing and validation.

I'm not interested in fighting around pull requests

Personally, I don't think fighting for a PR is really a thing here as we are very open to contributions. As you suggest, I also think that having a lite version of the images alongside the main images would be a very good approach. It would allow us to validate this and collect proper feedback from actual users without the risk of breaking things.

By decreasing the size of the image, we reduced the time of the unity-test-runner from 5.0 mins to 2.3 mins.

🙌 This sounds very promising assuming time is taken downloading the image over and over again.

I think another way around this is to use self hosted runners which will avoid downloading the image every time. This usually applies to Gitlab-CI and probably Github-Actions, I haven't tested this on github-action. I've also read somewhere that we can have the whole github-actions run in the context of the image (which actually leaded to the following issue: #72 ).

Definitely worth a try.

[snapshotpl]

Looks very promising! I have been build image with your snippet and works in our private CI like harm.

https://hub.docker.com/r/snapshotpl/unity/tags?page=1&ordering=last_updated

1:30 minutes per run saved!

[erdostamasa]

+1 for having a lite version of the images alongside the main ones
Any idea how complex/time-consumig would this be to implement?

[webbertakken]

We also support the idea of lite images and look forward to have them incorporated into the publication flow. We're open to discuss how it should be correctly implemented.

So first off I think the proposed Dockerfile is removing some things that will never be needed, especially in a lite image or in CI, so it would probably be universally applicable, which is great!

Also note that some CI setups allow for proper caching of images, i.e. by using local or predictable runners or mounting a network volume. In CI for games this may be generally favourable to get the best results. In cases where this is possible, there will be no real win with regards to time being saved per run.

Any idea how complex/time-consumig would this be to implement?

There are a few things to keep in mind.

There are multiple target platforms. We'll need to consider how far we want the lite images to take over time. For example, do we remove specific packages for android images much like OP did for the base target platform (Linux for ubuntu images); so we have to consider whether each target platform gets their own specialised Dockerfile in this repo, or we could have one for all of them.

Also most base images are in fact not really 3GB but somewhere between 1.4GB and 2.1GB. The increased size was introduced in 2020.2, which for all we know might as well be a mistake that would be removed later on.

I had a look and compared the default sizes (non-lite) of some of the images:

version	base	webgl	android
2018.4	1.32 GB	1.77 GB	3.52 GB
2019.1	1.35 GB	1.91 GB	3.05 GB
2019.4	1.98 GB	2.55 GB	3.42 GB
2020.1	2.06 GB	2.64 GB	3.51 GB
2020.2	2.97 GB	3.63 GB	4.41 GB

My observation from this is that the sizes can differ quite a bit both per target platform and between different versions. Notably 2018.4-android was the biggest version before 2020.2 came out.

Leaving further rationale out for brevity sake.

There are a few things to consider for the initial implementation:

• Will we use a Dockerfile per target platform or one for all lite images?
• We'll need to extend current workflows to also build the lite images.
• We'll have to set up triggers for lite images to build and report to the versioning backend.

Nice to have:

• This might seem unnecessary but versioning backend currently doesn't have a UI to recover failures, which makes debugging failed builds very tedious, as the whole process is automated. Creating this UI would greatly help debugging and recovering failed workflows, as there are some known edge cases that we've found running the last few thousand publications.

I might pick this up after getting v2 of the Unity Actions in. In the meantime feel free to open PRs and further discuss any details.

[zh99998]

It looks like linux-mono build support is included in base image, which maybe not need in windows and osx build.
move it to a seprate linux-mono image will make windows and osx image smaller?

[shadow7412]

I'm running sonarqube inside this container which requires the dotnet executable found in /opt/unity/Editor/Data/NetCore/Sdk-*, which is purged by this suggestion.

Just giving you an example of something this change would break. I do like the idea of -lite images though.

[webbertakken]

Sonarqube is about code quality. Can it be run as a separate step and from an image without the unity editor in it?

[shadow7412]

One of the required steps is to build the project, and I'm not sure how to do that outside of the unity image. Especially if you're using unity packages that need to be pulled in.

[vaind]

So are maintainers open to a PR adding a new "l/lite" images? I can prepare the PR if there's a reasonable chance it's going to get merged.

[webbertakken]

This is a pretty hard question to answer and it's not a yes or no answer that I can give you.

Currently every repoVersion-unityVersion-baseOs-targetPlatform combination is being built, totaling about 17TB I think every time we update the version of this repository. While storage at Docker is free for open source projects, we don't really know how far these limits go and we'd like to prevent an unnecessary full stop or obligatory deletion of image history other than 0.x versions.

That said, if we can create a multi-stage build mechanism in the editor docker file that makes image layers lay on top of each other instead of unique it would go a long way. Ideally it would looks something like this (this first part is current behaviour):

   base
  /    \
hub   editor

and for the editor specifically

  base                      <- this is already as pretty light but could be replaced for all images if needed
    |
  editor                    <- lite only
    |
  targetPlatform module     <- lite only
    |
  targetPlatform module     <- full - i.e. everything that was omitted in favour of lite image before

If you assume that the previous layer is always reused by the next layer, that would be the desired behaviour.

This or perhaps another architecture would allow us to fully support lite images because it would reduce our footprint.