A workflow for building releases on tag push #47
Conversation
This should help automate building test releases for both branches and the mainline. It takes a lot longer than building on a typical programmer PC with fast disks and warm caches, but it will generate reproducible builds and maybe reduce some of the by-hand work CS contributors are doing. The workflow generates a mod structure identical to the one the bat files generates, then compresses the result into a 7zip archive. The archive is then uploaded as an asset to a draft GitHub release named for the tag. To publish the release on GitHub, a human must edit the release notes and press the publish button. This workflow caches the cmake `build` directory. The vcpkg action caches the vcpkg binary artifacts. Most of the build time is currently spent rebuilding CommonLibSSE-NG because it's pulled in as a git submodule. Figuring out how to cache that build artifact on its own would speed this up a lot. (Maybe pulling it in as a vcpkg release instead? But that decision is above my pay grade.)
There was a problem hiding this comment.
We are currently planning to change to a GPL license for the repo. Please note your acceptance of that license change by approving that PR or commenting on that PR.
This is a good start but I believe one common use case we will have are features so we should probably address that use case. For example, if we got the PBR branch integrated, that is likely in the /features directory.
Also, while the GitHub action is one way to do the packaging, it may be worthwhile to do the packaging as part of CMake so it's handled on build.
The last two items I mentioned are suggestions and not required. I believe this is a good start regardless.
|
Comment left on the GPL PR. The features each get built into their own mods, correct? And there is no build step for them because they're shader-only, IIUC. What we can do is look at the paths changed when a PR lands and build mod archives for just those paths. I can absolutely do that as a next step. I'd normally build to support whatever the existing workflow is, but I haven't seen a release workflow happen with this project yet. All of these things can be done on PRs landing or tags being pushed, whichever the team prefers. The workflow is also triggerable via workflow dispatch, so you can do something like |
|
Oh, forgot to reply. Yah, personally I'd prefer some action to take the submodule to automatically build the port file. I debated manually creating a port, but then it's too much of a hassle to maintain both. Yah features are just manually dropping the ini, shaders, etc. into the directory as a separate package. I think doodles is still deciding on how to manage the repo; but I'm all for automation. I'm getting frustrated enough with copying files around that I was going to look at Cmake install step. |
|
Merging based on approval by @alandtse |
This should help automate building test releases for both branches and the mainline. It takes a lot longer than building on a typical programmer PC with fast disks and warm caches, but it will generate reproducible builds and maybe reduce some of the by-hand work CS contributors are doing.
The workflow generates a mod structure identical to the one the bat files generates, then compresses the result into a 7zip archive. The archive is then uploaded as an asset to a draft GitHub release named for the tag. To publish the release on GitHub, a human must edit the release notes and press the publish button.
This workflow caches the cmake
builddirectory. The vcpkg action caches the vcpkg binary artifacts. Most of the build time is currently spent rebuilding CommonLibSSE-NG because it's pulled in as a git submodule. Figuring out how to cache that build artifact on its own would speed this up a lot. (Maybe pulling it in as a vcpkg release instead? But that decision is above my pay grade.)ETA: GPL is fine by me.