Publish build products to a binary cache

[danielfullmer]

Requiring multiple hours of building is a major inconvenience for potential users. At the very least, publishing img files would allow someone to quickly test whether robotnix built images will even work for them.

However, we can do even better. Publishing unsigned "target files" on a binary cache would allow a user to run the final steps to generate their own signed img and/or ota files, without requiring them to run an hours long build process. This is better than simply publishing img and ota files signed by me personally. Since the user keeps control of their own keys, they still retain the ability to later switch configurations without losing userdata. This approach is especially interesting in light of https://github.com/danielfullmer/robotnix/issues/19.

Since each additional combination of flavor, device, and module option exponentially increases the number of possible configurations, it is infeasible to build them all. We would need to identify some subset of configurations to should build and publish.

Actually implementing this would require sufficient demand, proper build infrastructure, and somewhere to host the binary cache.

Arguably the best "bang for the buck" would be to first publish chromium app/webview apks, since building this takes hours and it is shared between devices.

[danielfullmer]

Initial support for this was added in 0e5898be781496978ffb3f077ab9445a5fc74310. For the time being, I intend to manually push all kernel and browser build products on each future release tag, but in the future we should integrate it with hydra or whatever CI we end up using. I'm using cachix now for convenience, but it's unclear if it will support the future multi-sig verification scheme I hope to implement. See https://github.com/danielfullmer/robotnix/issues/19 and https://github.com/cachix/cachix/issues/34 . Just keep in mind that the binary cache url and key might change in the future if the need arises.

[hmenke]

I think only publishing kernel and WebView is perfectly reasonable until Google commits to the generic system image. This is already a huge timesaver. Thanks a lot!

[YoshiRulz]

Would content-addressed derivations be beneficial?

[hmenke]

What would help the most is splitting up the Android build more fine grained. Daniel put some efforts into that with blueprint2nix and soongnix but it turned out to be not sustainable because the underlying formats are not stable enough. Maybe in the future Google will commit more to its own Generic System Image (GSI) proposal where images for all devices could be built by adding stuff to the GSI rather than building the entire image from scratch.