search

Astrabit-ST / ModShot-Core

A fork of mkxp, forked for OneShot, forked for OneShot mods, (not to be confused with the ModShot server)
https://nowaffles.com
GNU General Public License v2.0
19 stars 9 forks source link

Build ModShot for Windows using GitHub workflows #6

Closed rkevin-arch closed 3 years ago

rkevin-arch commented 3 years ago

This workflow will autocompile ModShot for Windows whenever there is a push to any branch, and you can download the compiled binaries as an artifact. Each build takes around 35 minutes, so it's not ideal, but for those who don't want to mess with Docker this is a valid alternative. Free GitHub users get 2000 minutes per month of GitHub Actions, and Windows has a 2x multiplier on time (so it bills ~70 minutes per compilation). This should let the average person compile ModShot 28 times in a month, assuming they don't use GitHub actions elsewhere. I'll look into not using a Docker container and somehow making conan work directly, but I'm not sure if it'll be faster without caching the conan build cache.

rkevin-arch commented 3 years ago

Here's an example: https://github.com/rkevin-arch/Modshot-Core/actions/runs/384875504, with its build artifact at https://github.com/rkevin-arch/Modshot-Core/suites/1565138850/artifacts/28137529.

rkevin-arch commented 3 years ago

Tested a new workflow, which does not use the docker container at all and just installs conan and compiles all dependencies. It takes a bit longer than the Docker version (45m), but you can cache the build cache for dependencies and make it as fast as 15 minutes after a clean build. Building the dependencies take ~36m, while restoring them from cache takes ~9m. I did not cache the ModShot build itself, which might shave another minute off, but is probably not worth it.

There are some limitations for caches, though. It only applies in the same branch (so you can't access the cache across branches, causing a full rebuild for each branch). The cache gets deleted after 7 days (so you have to be very active in terms of coding/testing), and has a 5GB size limit (would be an issue if you have many branches and many caches). This might still be useful for those testing out code changes rapidly.

I can close this PR and submit the build-without-docker-container workflow as a PR if you want (or maybe both, I'm not sure which one you prefer). Also, I can just add both workflows in the documentation if you prefer to not add a workflow to this repo, and whoever needs them can commit it themselves. None of the workflows are as fast as doing it locally (and requires you to commit+push for every compilation), but it's probably still useful for those who don't want to / can't run docker.

Speak2Erase commented 3 years ago

I can close this PR and submit the build-without-docker-container workflow as a PR if you want (or maybe both, I'm not sure which one you prefer). Also, I can just add both workflows in the documentation if you prefer to not add a workflow to this repo, and whoever needs them can commit it themselves. None of the workflows are as fast as doing it locally (and requires you to commit+push for every compilation), but it's probably still useful for those who don't want to / can't run docker.

It'd probably be better to add both in just to cover some weird edge case scenario, probably would also help to add in some documentation explaining workflows as well.