ci: Remove Nix Flake Checks #87
Conversation
While a theoretically awesome tool, Nix has demonstrated a pair of extremely deleterious shortcomings that appear to be not considered important by the Nix Community. Specifically: - Nix relies on the manual entry of input hashes for Cargo dependencies. This is extraordinarily cumbersome, and causes build failures on any dependency change. There was a suggestion to get this information automatically, but this has been stalled since 2019 (over 3 years, at the time of this commit): NixOS/nixpkgs#63653 - Nix appears to be unable to handle multiple versions of Rust packages gracefully. The result is unexpected and uncommunicative failures, such as a failure to generate a symlink. This class of failure was first reported in 2017 (over 5 years ago, at the time of this commit): NixOS/nixpkgs#22177 As a result, I do not believe that Nix can offer us a reliable platform for CI of Hubris at this time. As observed on #46, attempting to appease Nix can result in significant crate changes to facilitate single revision jumps - consuming days of effort to validate a change that is essentially operational.
|
I've added this as a separate PR to avoid polluting #46 with further non-Supervisor discussion. I can't see how we land #46 without this change. The required changes to get Nix to play nicely appear to involve forking a number of our indirect dependencies to reduce the number of duplicated versions - but even having done so we're still left with a system that is more clumsy that git submodules (in that we have to not just use VCS commands to manually update a fixed tie, but we have to go hack a central file list of hashes). |
|
We will need to come up with an alternative for the CI pipelines in gitlab. I use nix to generate various images for running in the simulator. Will probably have to replace it with a bash script or something. |
I think we might want to do this as part of a separate builder repo and not individual component repos. |
ghost
enabled auto-merge (rebase)
|
This isn't what I expected - the merge is blocked waiting for the tests I'm deleting to report their status - can we circumvent that for this merge? |
|
|
The required CI checks are done in the GitHub settings. I'll remove them from the list, then this should be fine. |
Actually, I found it. Should be good to go. |
While a theoretically awesome tool, Nix has demonstrated a pair of extremely deleterious shortcomings that appear to be not considered important by the Nix Community.
Specifically:
Nix relies on the manual entry of input hashes for Cargo dependencies. This is extraordinarily cumbersome, and causes build failures on any dependency change. There was a suggestion to get this information automatically, but this has been stalled since 2019 (over 3 years, at the time of this commit): Cargo build without cargoSha256, use Cargo.lock instead NixOS/nixpkgs#63653
Nix appears to be unable to handle multiple versions of Rust packages gracefully. The result is unexpected and uncommunicative failures, such as a failure to generate a symlink. This class of failure was first reported in 2017 (over 5 years ago, at the time of this commit): [replace] doesn't replace in rustBuildPackage NixOS/nixpkgs#22177
As a result, I do not believe that Nix can offer us a reliable platform for CI of Hubris at this time. As observed on #46, attempting to appease Nix can result in significant crate changes to facilitate single revision jumps - consuming days of effort to validate a change that is essentially operational.