ci: Migrate CI jobs to use Nix environment

[pbeza]

Background

Currently, the CI pipeline (.github/workflows/ci.yml) and the Nix development environment (flake.nix) maintain separate version definitions for shared tools like cargo-deny, cargo-nextest, cargo-shear, cargo-sort, zizmor, etc.

This leads to several issues:

• Maintenance overhead: Updating tool versions requires changes in two places
• Version drift: Easy to miss syncing versions between CI and Nix, causing local vs CI discrepancies
• Developer experience: Developers cannot run CI checks locally in exactly the same way as on remote CI

As discussed in #1738 (comment), migrating CI jobs to use Nix would unify the environment, ensuring developers and CI have the exact same tooling and versions.

User Story

No response

Acceptance Criteria

• CI jobs use the Nix environment defined in flake.nix instead of installing tools via cargo binstall or other methods
• Tool versions are defined in a single source of truth (Nix flake)
• All existing CI checks (clippy, fmt, deny, nextest, shear, sort, etc.) pass using the Nix environment
• CI runners have Nix installed and configured with flakes enabled
• Documentation updated to reflect the new CI setup
• Local nix develop environment produces identical results to CI for all linting and testing jobs

Resources & Additional Notes

• build(rust): add support for Nix build environment #1738 (comment)

[DSharifi]

I think it's a bit early to create this task

We should definetly get agreement from rest of the team before pushing for using nix.

We also need to nixify all of our remaining dependencies as a prerequisite before we attempt this

[pbeza]

I think it's a bit early to create this task

We should definetly get agreement from rest of the team before pushing for using nix.

Let’s do this async here then! @netrome @gilcu3 @kevindeforth @DSharifi — WDYT about running CI with Nix? That would mean nixifying all dependencies and having a unified environment for both CI and local dev.

The biggest win for me is being able to run CI checks locally exactly as they run on CI (same dependency versions), and having a setup that’s fully reproducible on any machine.

If we ever wanted to rip out dstack (for whatever reason — not saying we’d need to, but who knows), having a fully nixified, very slim/light environment would make it much easier to migrate to an alternative. That’s essentially what we did at Matter Labs with teepot, where we ran a much more lightweight TDX environment with a significantly smaller TCB, without using dstack.

The main downside is that Nix would be new for most of us, so there’s a bit of a learning curve to understand the syntax.

Any thoughts?

We also need to nixify all of our remaining dependencies as a prerequisite before we attempt this

Which dependencies do you have in mind? Aren’t the ones you’ve already nixified (#1738) sufficient to run everything (or most of it) in CI?

[netrome]

Let’s do this async here then! @netrome @gilcu3 @kevindeforth @DSharifi — WDYT about running CI with Nix? That would mean nixifying all dependencies and having a unified environment for both CI and local dev.

Love the idea! Having a more consistent environment with our CI sounds like it would save us a lot of time in the long run.

[gilcu3]

Let’s do this async here then! @netrome @gilcu3 @kevindeforth @DSharifi — WDYT about running CI with Nix? That would mean nixifying all dependencies and having a unified environment for both CI and local dev.

I am not against it as long as we keep things optional locally. My only fear is that if strange things happen in CI, nix will make it much harder to figure out. It could also make it much easier, if it is really a mirror of the local env, so we can certainly try it

[DSharifi]

I'm all for reproducibility and being able to run CI checks locally would indeed be awesome.

However, I want to make sure we are aligned on the scope of this issue. There is a big jump from using Nix as a development environment, what I added in #1753, and using Nix as the actual build system for CI.

If we want to use Nix for reproducible CI, it means that we want to use Nix as our build system. This is a much more complex task, as it will require more infra type of work, probably involving pulling in something like naersk or crane. Then we also have to figure out how to nixify the github actions we depend on, and set up good caching mechanisms for the flakes which is not as easy with action to best of my knowledge. There are probably other obstacles that are unknown to me.

If someone has time to learn Nix properly to build out all this infrastructure and maintain it then I am happy to switch. But I think it will also lock us in to maintain it, and that can be costly like @gilcu3 mentions.

@pbeza have you thought about which approach you want to go with for using nix environments in CI checks?

[netrome]

It's not obvious if this will degrade our CI performance, but @DSharifi is experimenting with this in #2091 so soon we should have hard numbers.