Repository navigation
ci: Migrate CI jobs to use Nix environment #1760
Description
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.nixinstead of installing tools viacargo binstallor 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 developenvironment produces identical results to CI for all linting and testing jobs
Activity
DSharifi commentedon Jan 14, 2026
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 commentedon Jan 15, 2026
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?
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 commentedon Jan 15, 2026
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 commentedon Jan 15, 2026
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 commentedon Jan 15, 2026
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
naerskorcrane. 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 commentedon Feb 16, 2026
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.
DSharifi commentedon Mar 30, 2026
If the
cache-nix-actionor another nix action get's support for WarpBuild's cache then this would become more streamlined to implement.An issue was opened recently to support warpbuild; nix-community/cache-nix-action#311
netrome commentedon Jun 8, 2026
Basically resolved in #3058, except builds. The builds were added in #3052. Not sure where the final migration to the job happened but it seems like we're only using nix to build our node and contract in our development workflows. The only exception is reproducible release builds, and we can migrate that separately - i.e. doesn't need to be tracked here.