Future of Android binary factory builds

[Nicolas Fella]

Hi,

this is a breakout of https://mail.kde.org/pipermail/release-team/2019-December/011702.html since it's not really relevant for the release team.

The Android binary factory currently serves two purpose. It serves as a CI
system in the sense that it catches (compiletime) breakages and it provides
nightly APKs for beta users.

Given that we already have a few applications on Google Play and it's likely
that more will join in the future I would like to expand the scope of it to
also provide release builds from it, i.e. from stable branches, with binaries
built in release mode etc. This aims to replace the custom solutions some
projects have built for themselves.

On Donnerstag, 12. Dezember 2019 18:54:28 CET Ben Cooksley wrote:
> With the way Android builds are currently conducted (building every
> single dependency from scratch each time) i'm opposed to doing this as
> it would double what is already quite an expensive load on the system
> already.
>
> I'd like to see the Android build process optimised to let it reuse
> the results for most dependencies (Frameworks come to mind in
> particular) before we head in that direction.

Assuming that the general approach of using Docker for the builds is fine I
would like to propose this:
We provide a base image that contains the most common depenencies prebuilt,
i.e. Qt and the main Frameworks. We provide this in two variants, stable and
unstable. Stable would provide the latest frameworks release and would thus be
regularly rebuilt once a month after the Frameworks release. The unstable
version would contain a master Frameworks build to keep the CI/nightly aspect
of the builds. This would be rebuilt more often, i.e. once a day. This would
require a full Frameworks build per day which is still an improvement over 20
full Frameworks builds per day as we have now. With regard to the Qt version I
think sticking to the latest release as we do now is fine for both. A solution
that would not need a full Qt build once a day would thus be preferrable, e.g.
by using prebuilt Qt binaries or factoring out the Qt build into another base
image. Application builds then would pick an appropriate base image, build the
non-framework dependencies and finally the application itself. This should
reduce the non-necessary frameworks rebuilds by a significant amount.

@Ben do you agree with this proposal?

Cheers

Nico