Speeding up CI

[yavko]

So CI is kinda slow

Here are some of the ideas I have for speeding it up

• Each time CI is started it's initializing a new container without the compiled deps from previous runs, and so gh actions' built-in cache functionality could be used, here is how hyprland-rs uses it https://github.com/hyprland-community/hyprland-rs/blob/master/.github/workflows/build.yml
• And of course speed optimization flags could be added
• Nix builds are slower and can't be cached like normal builds, so maybe a faster builder with caching like crane or naersk could be used! (I can implement and benchmark both of them) (And even better this would speed up builds for users using ironbar with custom flags in nix!)
• If anyone else has more, feel free to share them!

[JakeStanger]

Yeah agreed, the build times are a little lengthy. I'll definitely look at setting up caching and any optimisation flags.

Obviously it doesn't matter how fast the main build is if it still has to wait for the Nix build, so if you have ideas for Nix then go for it!

One thing that's been on my mind for a while - does the build CI actually need to do the full build, or is clippy enough? That'd shave a good few minutes off straight away.

[yavko]

One thing that's been on my mind for a while - does the build CI actually need to do the full build, or is clippy enough? That'd shave a good few minutes off straight away.

In Hyprland-rs I do rustdoc, clippy, and a build, but I'm pretty sure clippy could be enough. In Hyprland-rs I've noticed it's about 50% faster than a regular build (with caching)

[yavko]

For nix in ci there is a new gh action that can cache the nix store https://discourse.nixos.org/t/the-magic-nix-cache-a-github-action-for-speeding-up-your-nix-workflows/29665

[JakeStanger]

Looks like it hasn't worked :(

[yavko]

Looks like it hasn't worked :(

Yeah cuz dependencies aren't cached with default builder, let me try making a PR to switch it rq

[yavko]

Okay so I got crane working, I'll implement naersk, and then we can benchmark, cuz I made it switchable lol

[JakeStanger]

It doesn't look like crane is working unfortunately. It's populating the cache, but never actually seems to hit it when starting a build, which means it's actually taking longer than before. If you get a chance to switch it, let's do that and see.

EDIT: Is it using naersk already actually? It shows up in the logs at least

[yavko]

It doesn't look like crane is working unfortunately. It's populating the cache, but never actually seems to hit it when starting a build, which means it's actually taking longer than before. If you get a chance to switch it, let's do that and see.

I noticed that as well it makes no sense to me

EDIT: Is it using naersk already actually? It shows up in the logs at least

Yeah we switched it

[JakeStanger]

@yavko I've just installed Garnix into the repo and it's massively sped up the Nix build, looks like caching works properly.

I'd ideally like to remove the build-nix GH action job and rely on Garnix instead. What are the logistics of doing that and keeping a Cachix instance around for people to use? Is it just a matter of pointing people to the garnix cache instead of my own?

[yavko]

Is it really faster? On GitHub it says the nix build over garnix for the latest commit took 12m vs the 6m of GH actions.

[JakeStanger]

It did for the first build, after that the cache kicks in properly and it takes about a minute for Garnix while the GH actions remains the same. Also avoids the job queue time