build-containers
build-containers copied to clipboard
godotengine
Add image build log to the image for documentation purpose
@hpvb @tinmanjuggernaut
Do you know of an easy/idiomatic way to include the build logs from the image generation as a file in the image itself? (Like /root/image_build.log.)
We currently log the last builds to the logs folder in this repo, but they're not tied to the built image and will be replaced by subsequent builds.
Having those logs directly in the image would be useful to review what options were used in the build and whether any issues went unnoticed (like #44).
Maybe rather than having 10-20 commands in the docker RUN entry, have the docker RUN build-windows.sh | tee /root/build.log.
I don't know how to commit changes to an image after it has been created, and podman documentation sucks.
Alternative option: Build the containers using continuous integration?
GitHub Actions would be free and easily available, but other options (Drone, Jenkins, Travis, etc...) would work too. Then the logs would be publicly available.
I have some experience with building Docker images on GH Actions, so if this platform would be preferred, I'd start working on a PR...
From GitHub Actions Job execution time:
Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
So, using CI might not be a solution here, as building everything could take 5-10 hours according to #12.
@Xrayez Wouldn't one run several simultaneous CI jobs for each of the 30+ binaries? They don't all take 5-10 hours. It's 5-10 hours ran sequentially, including all downloading and building, or it was back then. The scripts may have been changed a little since.
True, just to be aware of the limits. Also, I'm not sure how many concurrent jobs are allowed at GitHub Actions, which may also be queued, but the workflow run is restricted to 72 hours, so I guess this shouldn't prevent running this on CI.
I think it takes more than 5-10 hours to build all containers unless you have a very powerful machine, which is not the case with CI. Note that when that README was written there was no Mono build for Android and iOS (not sure if there was WebAssembly yet), but nowadays building everything takes me several hours on a threadripper with 64 jobs.
I'm not particularly interested in moving this to CI, it will never be as fast as the buildsystem I have available. Having a CI config that can build the containers is fine, but keep in mind that several of the containers depend on materials that you are not allowed to redistribute (Android SDK/NDK, macOS SDK, iOS SDK, MSVC).