I am building a new application based on Godot game engine. I had it working using a local fdroid server instance, but the build pipeline in gitlab fails with a timeout error, since just building Godot from sources takes more than 1h. I am quite a newbie regarding Android builds and F-Droid workflows. So, how to proceed from here?
Increasing the timeout (how)? Using any prebuilt Godot binaries (how)? Since the build is working in local, just remove the draft flag in the PR and let the maintainers fully build it? Splitting platforms in different builds (how)?
Apparently you need to bump the timeout in the CI settings: New App: IED (!17260) Ā· Merge requests Ā· F-Droid / Data Ā· GitLab
I think F-Droid should allow prebuilt binaries for Godot since itās becoming increasingly popular and it takes a long time to build.
Thanks for the tip. I though the timeout was system wide. I will try changing the settings. But i need 2h or more. It is huge since every platforms must compile its template apk. In one hour it compiled the native linux editor and half a architecture template of 4. I could reduce the supported architectures by building just arm and arm64.
I was thinking on just downloading godot upstream binaries, but i donāt know if this goes against the ābuild all from sourceā policy. Godot editor is not the project itself, it could be treated as āantā or any other build tool. The templates may be different since they are compiled code distributed along the app.
If I download such binaries dependencies directly from upstream will my package be bounced to get into the repos?
Canāt you split by ABI? Build only one arch?
I hardly managed to build just two arm archs in a single job/apk, by disabling intel ones, and extending the timeout. No idea on how to have a diferent job or build to build the remaining ones. Any hints?
Just wanted to clarify that I didnāt mean to suggest developers should upload their own APKs for Godot applications. I was referring to export templates. As you noted, this includes compiled code that will be published. But Gradle already downloads compiled JARs for more conventional Android projects. I donāt think that downloading Godot export templates would be any different, as long as they are downloaded from a trusted source and checked (e.g., using SHA-256).
Only downloading the Godot editor may be a good middle-ground since there seems to be some disagreement about my suggestion. But as I said, IMHO itās not any different than downloading pre-compiled dependencies, so I would love to hear the other side of the argument.
Inclusion policy doesnāt explicitly mention Godot, but downloading the binaries from the developer seems to be a common pattern for many other dependencies: Flutter SDK, JSC/Hermes (long build times are cited as the main reason for downloading), pip wheels, Rustā¦
A Godot package is actually available on Debian, but its version is 3.6, not 4.x. Also, it probably doesnāt include export templates, but it might be useful for Godot 3 users (as the inclusion policy tends to favor Debian packages whenever possible).
Finally, since F-Droid already has Godot Editor, it may be possible to get export templates from that. Alongside the editor APK, Godot Editorās build script could build export templates, which can be used by other F-Droid apps. However, I am not sure how feasible this is to implement.
are those included in our editor APKs that we publish?
Current F-Droid Godot builds donāt include export templates. To build these, target=template_release setting must be used instead of target=editor. See Godot documentation for more.
I think compiling the export templates after building the editor would be quick since most of the code is shared.
Relevant maintainer note from org.godotengine.editor.v4.yml:
Upstream also provides android export templates in form of APKs, however, exporting projects is currently not supported in the android version of godot editor, so thereās no point in building them.
This info is outdated. Godotās Android Editor has export support now. See Godot 4.4 release notes.
I think compiling the export templates after building the editor would be quick since most of the code is shared.
Indeed it is not. This is what i did and it takes almost an hour per each architecture. Every architecture needs its own compilation.
But having it done once for Godot and being able to use that from any project using godot will certainly speed the compilation of those projects. Moreover, having a multiarch template, makes that projects using Godot, generate also multiarch apk in a single step.
After reading the thread, I still wonder whether i could use upstream binaries from Godot. If so, all the building will simplify. I already used that approach in other platforms and works neatly.
My idea was: since we build the editor, maybe those can be included, and other recipes like yours could download the APK and extract them during build.
Good trick?
The answer is noā¦ But see my post above, since maybe we can provide whatās needed 
I was talking about building the export templates after building the Android editor there, not the Linux one. You are currently building the Linux editor and Android export templates for each arch. Thatās why itās taking so long.
Since we were discussing F-Droidās Godot editor builds, I mentioned that building the export template after compiling the editor for a given Android arch would only incur an incremental cost.
Maybe this could be implemented using version codes, similarly to how archs are currently separated in Godot editor? For each architecture we would have two version codes: one for the editor and one for the export template. The users download the editor, developers using Godot download the export template. Or maybe your CI environment may allow a simpler mechanism to produce export template output alongside the editor APK.
Also, to use the export template, you need to have the Godot editor binary (not the Android editor) in your development environment as well. Even if we solve the export template problem, we would still need to build that. Again, consider downloading it (since it acts more like a development tool as itās not included in the output APK unlike the export templates) or building it once and reusing for many projects like the export templates.
I tried. Anyway, if the only ābadā thing is the time it takes to build, then itās not that much of an issue. 
Is there any community process we could start in order to promote Godot into the list of exceptions in Inclusion Policy | F-Droid - Free and Open Source Android App Repository
Godot compilation, even if it is just the editor, really makes the build process slow, it is not a problem when all goes right but, having to iterate to fix problems, getting that feedback hours later, when you have lost the whole focus is really a pain. A problem with your project wonāt show up until the editor and at least one template has been compiled. That means one and a half hour. In contrast, godot exporting just takes few minutes if you already have the editor and the template.
At least that would be nice for the editor which is a linux binary that does not get into the android package.
you can always test with a prebuild until you get the android part of the recipe right
and then when ready, just add the editor&template lines
Forgive me for over-asking. This is really almost the first thing i do in Android and i donāt know the jargon and technicalities. Not to speak about FDroid pipelines and conventions. I have been 3 weeks hitting walls and i am kind of frustrated with the process. I am sorry if i am kind of conservative in where to put more efforts.
My metadata is generated with a script, this eases updates but adding multiple version codes for each arch requires changes, they should be kind of easy, but testing and iterating the results with long compilation times turns it very hard. For me would be more efficient to test with just one architecture, and, when it works, enable a long timeout to build a multiarch binary, if that follows FDroid policies. Right now i am not even sure that the current two-arch build is fully ok. It is?
Your idea of doing the testing with prebuilt binaries and then, turning into code based, is a good one to start from scratch, but in my experience while doing this and other builds (github, flatpakā¦), most errors happen just in the configuration on how to tell the project build process where to find the templates and other stuff that may change when you change from prebuilt to source based. So doing the effort to change the build to use prebuilt binaries would be worth for me if it is a one way trip. If prebuilt Godot becomes legit.
Thatās why i was wondering if there is a chance that the community will accept prebuilt Godot binaries to be added to the exception list and how to push that. Or this is something to be avoided at all costs. if that is the point, i would go for the multiarch binary after testing with single arch, if thatās ok.