godot-proposals
godot-proposals copied to clipboard
godotengine
Generate export template set as GHA artifact
Describe the project you are working on
A VR game, which I'm attempting to use Godot's master branch for so I can contribute to the engine.
Describe the problem or limitation you are having in your project
Recently I was updating my VR game to 4.5.dev, and ran into a lot of trouble with getting the correct export templates. My solution was to download 4.4.stable export templates, manually rename them to 4.5.dev, and place them in my export template folder. Since there hasn't been much work done on 4.5 compared to 4.4 at this point, this works, but in the future I could certainly see there being compatibility issues.
I could be building my own export templates off of master, but that takes a lot of extra time even if they're successful. Attempting to build export templates for Android has given me some difficult errors that I would have to spend time sifting through and fixing.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Produce a project export template TPZ/ZIP file as an artifact of the GitHub Actions tests/workflow that users can download. It looks like the following export templates are already being built:
- Android, release, arm32
- Android, release, arm64
- iOS, release
- Linux with Mono, release, with tests
- Linux with Mono, debug, with tests
- Linux minimal, release, with tests, "everything disabled"
- macOS, release, with tests
- Windows, release, with tests
- Web, release, with threads
- Web, release, without threads
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
GitHub Actions will produce a TPZ file in the same format as provided at https://godotengine.org/download/ under "All Downloads" > "Export templates".
If this enhancement will not be used often, can it be worked around with a few lines of script?
A user could set up a shell script to generate a full set of export templates and package it into a TPZ file that they could then install (or, the script could install the templates itself). However, this would require a lot of time and processing power from the user.
Is there a reason why this should be core and not an add-on in the asset library?
It is an improvement to the GitHub workflow for Godot, not the engine itself.
The issue is that generating the TPZ must be done after all export templates are built, so we'd need to wait for all the jobs to be completed before the TPZ must be generated. Also, if certain jobs fail, we should still generate a TPZ with the failing platforms not included. (Otherwise, you wouldn't be able to download any of the export templates.)
We would also need to remove the temporary export template artifacts that are used to pass data around to the TPZ generation job, as we need to avoid reaching the 10 GB storage limit for artifacts.
Also, I don't remember if the Export dialog handles situations well where only debug (or only release) export templates are installed for a given platform. It should disable the unsupported actions in the UI automatically, such as making the Export with Debug checkbox disabled in the export dialog when only debug (or only release) export templates are available.
The issue is that generating the TPZ must be done after all export templates are built, so we'd need to wait for all the jobs to be completed before the TPZ must be generated.
I'm not sure why this would be a particularly big issue. The export template set would certainly have to be one of the last artifacts produced, but I feel like this would be fine. In most cases, we'd probably be able to grab the TPZ generated from a previous commit.
Also, if certain jobs fail, we should still generate a TPZ with the failing platforms not included. (Otherwise, you wouldn't be able to download any of the export templates.)
I would think that, if a job fails, that version of the Godot code would be considered "invalid" and people would be advised to not use TPZs generated from it. Instead, they could again download an earlier commit's TPZ instead.
We would also need to remove the temporary export template artifacts that are used to pass data around to the TPZ generation job, as we need to avoid reaching the 10 GB storage limit for artifacts.
That definitely sounds like it'd be an important consideration. I see that the 4.4 export template TPZs for regular and .NET together are about 2.33 GB, according to my computer, which is quite a significant chunk of the 10 GB limit. This leads me to wonder if there might be a different, more efficient way to accomplish something similar, like a nightly build, so that there is always a fairly recent TPZ available for download, while also putting less strain on the GitHub resources.
We generate the export templates and split them in https://github.com/V-Sekai/world-godot ‘s releases
See also: https://github.com/V-Sekai/world-godot/blob/main/.github/workflows/build.yaml
We also nightly prune the list of non tagged releases: https://github.com/V-Sekai/world-godot/blob/main/.github/workflows/nightly-prune.yaml
Thirdly by using justfiles and github actions, we preserve local only development.
