IDK if the sheer quantity of builds we're currently running in nixvim is contributing, but we're running into buildbot issues with cross-comp/available builders rather frequently, leading to us having to rebuild to get a green checkmark (putting even more strain on resources)...

e.g. this is from a recent build (from this eval):

Failed to find a machine for remote build!
derivation: ycm30n2fwjwycmx3hi21gvn1q4kr04yy-plugins-ui-zen-mode.drv
required (system, features): (aarch64-linux, [])
2 available machines:
(systems, maxjobs, supportedFeatures, mandatoryFeatures)
([aarch64-linux], 80, [benchmark, big-parallel, gccarch-armv8-a, kvm, nixos-test], [])
([aarch64-darwin, x86_64-darwin], 8, [big-parallel], [])
error: a 'aarch64-linux' with features {} is required to build '/nix/store/ycm30n2fwjwycmx3hi21gvn1q4kr04yy-plugins-ui-zen-mode.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

I've seen that occur a few times in other projects on buildbot as well.

I'm wondering if we can group our tests a little more whether that'd help; that way there'd be a smaller number of bigger builds.

We split them up so much originally to reduce RAM usage. But it's ended up causing other issues, such as many small builds waiting for builders to become available.

For now the rebuilds aren't too much strain on our resources.

That's reassuring!

e.g. smarter scheduling and making no op rebuilds faster.

Yeah only rebuilding the failed builds would be good. Cancelling an eval & its builds when a new one is triggered on the same PR could be worthwhile too, at least on repos where the builds are heavy?