Skip to content
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

Add image build log to the image for documentation purpose #45

Open
akien-mga opened this issue Apr 6, 2020 · 6 comments
Open

Add image build log to the image for documentation purpose #45

akien-mga opened this issue Apr 6, 2020 · 6 comments

Comments

@akien-mga
Copy link
Member

@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).

@TokisanGames
Copy link
Contributor

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.

@Filius-Patris
Copy link

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...

@Xrayez
Copy link

Xrayez commented Oct 8, 2020

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.

@TokisanGames
Copy link
Contributor

@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.

@Xrayez
Copy link

Xrayez commented Oct 8, 2020

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.

@akien-mga
Copy link
Member Author

akien-mga commented Oct 8, 2020

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants