| 26 Apr 2025 |
 KFears (burning out) | I already have a NixOS test for it | 21:43:43 |
| KFears (burning out) | It's not too bad | 21:43:55 |
 K900 | Not a test but a long-lived VM with ports forwarded from localhost | 21:44:17 |
| K900 | So you basically treat it just like any other remote box | 21:44:28 |
 Winter | In reply to @k900:0upti.me
We have good tools for those like? | 21:44:35 |
| KFears (burning out) | I mean, maybe it makes sense to spin up a parallel VM in a NixOS test to SSH into and spin up Garage there, but like whatever | 21:44:39 |
| K900 | Like nixos-rebuild build-vm | 21:44:45 |
| KFears (burning out) | I don't have all of the stuff I actually have pushed | 21:44:50 |
| Winter | oh. well yeah. | 21:44:52 |
| KFears (burning out) | And also last time I got stunlocked on the building part because like, the whole setup where n-e-j is used in staging/prod to get the list of derivations to push to Garage doesn't work at all in NixOS VM, and will never work | 21:45:59 |
| KFears (burning out) | So I need to do a refactor there for the code to be more abstract and for n-e-j and Nix-native stuff being able to create internal Dataclass representation that can be passed around | 21:46:58 |
 jade_ | wait what | 21:48:03 |
| KFears (burning out) | And there's also a pretty large differences in artifacts that make sense to be uploaded in a local test vs ones that make sense to be uploaded in staging | 21:48:10 |
| jade_ | how is that not possible? | 21:48:12 |
| jade_ | nix-eval-jobs should always be used | 21:48:43 |
| KFears (burning out) | I don't remember the exact details, I remember running into very annoying situations because NixOS VM doesn't have egress connectivity to pull the flake for evaluation from the internet, and passing it as an evaluated store path from the host also ran into some issue where n-e-j wanted to download something from binary cache to be able to evaluate stuff | 21:50:26 |
| KFears (burning out) | And it ran into this shitty problem where unless you run n-e-j on the host first, the VM invocation will straight up fail | 21:50:48 |
| jade_ | that sounds like you either want to have egress connectivity in the test (acceptable in principle but not preferred) or figure out a way to pre-seed the necessary things. | 21:51:50 |
 raitobezarius | Sounds like missing store paths in the VMs, the installer tests in nixpkgs are probably working in a similar way as what should be done here | 21:51:53 |
| jade_ | but in the end it is just a thing that one has to solve | 21:52:11 |
| KFears (burning out) | If you can pre-seed the necessary things, there's no use for n-e-j, because pre-seeding will already evaluate all the necessary stuff | 21:52:56 |
| jade_ | no, the pre-seeding would just be the inputs | 21:53:14 |
| jade_ | but also, building an entire lix in a vm is not ideal | 21:53:24 |
| KFears (burning out) | The whole point of n-e-j in the script is to not pre-seed, and instead to just do it at runtime | 21:53:26 |
| jade_ | the point of the vm test is to verify that releng works, and if the thing being evaluated already exists and was built that's like fine | 21:53:55 |
| raitobezarius | There's no easy way to pass pre-computed evaluation results across the boundary, short of solving that which is an adventure on itself, evaling twice is not problematic on its own | 21:55:03 |
| raitobezarius | It's an optimization concern to do it once | 21:55:25 |
| jade_ | the things that definitely need to get into the VM are things that get downloaded from the world wide web | 21:55:43 |
| KFears (burning out) | Yeah, hence why I wanted to sidestep the whole n-e-j thing because it also wants you to have evaluated and built artifacts for the whole matrix of [linux, darwin] and [x86_64, aarch64], which is impossible to do locally unless you own a datacenter at home | 21:55:48 |
| KFears (burning out) | Because really, to verify that releng works, you can just have the artifacts for your system and that's it | 21:56:07 |
