Automate building and pushing packages with overlays?

[Gerschtli]

As we recently introduced an overlay for htop and I think that there will be many overlays created in the future (see termux packages and their patches), we should think about a build environment which will push the built packages to cachix.

We could use aarch64 build machine like those provided by travis-ci or github workflow to build these packages. Or we could consider using a custom android phone as build machine via hercules-ci or github workflow self-hosted runner or anything with a matching architecture if there are any compatibility issues between aarch64 machines and the android/bionic env. Maybe there are other options to automate this.

In the htop overlay I pinned the nixpkgs version. This provides us with the possibility to update the pinned version, build and push all packages and only on success commit and push the new rev of the nixpkgs version. This could be easily automated with github workflow for example.

My main intention behind all of this is to prevent (re)builds on client devices but also to update the pinned nixpkgs version regularly to prevent outdated packages.

What do you think? Are there any problems I missed out?

[t184256]

As we recently introduced an overlay for htop and I think that there will be many overlays created in the future (see termux packages and their patches)

I've looked through a couple of dozens of them, and I got the impression that most of their patches aren't relevant for us, they are for fighting bionic/NDK pecularities. So, I'm not exactly sure that we'll have too many.

We could use aarch64 build machine like those provided by travis-ci or github workflow to build these packages.

I actually liked how you did it with travis and cross-compilation. Large builds might require manual pushes, but small changes and small builds like htop should be within sane limits. And it auto-pushes what it has already built, so it will get through eventually.

In the htop overlay I pinned the nixpkgs version.

Yes. I was puzzled at first, but I concede that it makes sense: nixpkgs can move forward and break our patches, while a pinned old version of htop that you have to compile yourself is still infinitely better than a guaranteed broken one.

What do you think? Are there any problems I missed out?

Your reasoning is fine. Configuring CI for native compilation will be a big one-off investment. Updating pinned nixpkgs will be required from time to time, but having the packages compiled and cached will allow to reduce the period.

Patching packages that were half-broken is another story, and we'll have to expose the choice to the user: fresh package or fixed package. But it's thinking too much ahead, we don't even have them at this point =)

[Gerschtli]

Large builds might require manual pushes

A side note: travis has a timeout of an hour, github workflow has a timeout of 6 hours.

I try to build a prototype which builds ci.nix and all packages with overlays and push them to cachix. Furthermore I will write a workflow to update the nixpkgs version if all builds succeed, should be fairly straight forward :)

[Gerschtli]

Unfortunately, it is not really easy to pull off a working github workflow as it does not support aarch64. I could try travis for this purpose, but I don't think the one hour limit will work for us.

[t184256]

For what, just for htop?

[Gerschtli]

Thats a valid point. As long as the count of overlays is low it should work.

[t184256]

If we update them one-by one, it's not the count that matters, but the duration of the rebuilds. Or even of a single derivation, if we're willing to retrigger timeouts.

Which reminded me that I wanted to fix typespeed for quite a while already, I'll try my hand at it...

[t184256]

I've pushed 8e97da4 with a fix for typespeed, but deliberately didn't push the resulting binaries to cachix. It's also not a big package.

[Gerschtli]

Short update on this topic. I managed to pull off a complete CI job (install nix, setup cachix, build stuff, push to cachix) on github actions for aarch64 systems in my nix-config repo: https://github.com/Gerschtli/nix-config/blob/master/.github/workflows/ci.yml

It is not that complicated, maybe it is worth a try for nix-on-droid :)