Automate building and pushing packages with overlays? about nix-on-droid

[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 :)