| 17 Aug 2023 |
 @infinisil:matrix.org | Yeah that would be nice too | 23:35:42 |
| @infinisil:matrix.org | Related: https://github.com/NixOS/nix/pull/8699 | 23:35:52 |
| @infinisil:matrix.org | That has a bunch of nice implications for Nix CI | 23:36:09 |
 Lily Foster | Oh sweat, yeah. And stuff like nixd even | 23:36:22 |
| Lily Foster | (and reduce some of the cross-language hacks I've seen to interface with the libs from rust and whatnot too) | 23:36:55 |
| @infinisil:matrix.org | In reply to @infinisil:matrix.org
I could probably come up with a hacky but reliable way to do that in a day Oh, problem: All packages need to evaluate all-packages.nix, so if you update that, all packages could've changed for all Nix knows | 23:38:43 |
| @infinisil:matrix.org | RFC 140 unintentionally seems to help here | 23:39:04 |
| @infinisil:matrix.org | cole-h: Anyways, regarding the RFC 140 CI check, I'll try to see how it could be integrated into ofborg. If it's easy I'll probably make a PR | 23:46:18 |
| @infinisil:matrix.org | (as much as I want to help fixing ofborg, I can't always get stuck in rabbit holes!) | 23:48:17 |
| @infinisil:matrix.org | * (as much as I want to help fixing ofborg, I can't always get stuck in rabbit holes! RFC 140 should get done first :)) | 23:48:33 |
| @infinisil:matrix.org | I slowly get what you meant by ofborg being a mess | 23:52:40 |
| @infinisil:matrix.org | It's like 10000 lines of uncommented random-looking code | 23:53:05 |
| 18 Aug 2023 |
| @infinisil:matrix.org | cole-h: https://github.com/NixOS/ofborg/tree/cda5aa2ac77a70bb5660d8d5614a640aacbe7523/ofborg/src/tasks/eval looks like it was made to support non-nixpkgs repositories. Is ofborg actually used on non-nixpkgs repos? | 14:03:10 |
| @infinisil:matrix.org | And if not, could I just send a refactoring that removes the generic code? | 14:03:26 |
 cole-h | If it's only the refactoring in that PR, I'd be happy to take a look, sure! | 14:04:53 |
| @infinisil:matrix.org | cole-h: https://github.com/NixOS/ofborg/pull/649 | 14:33:31 |
| 19 Aug 2023 |
|  @ninjatrappeur:alternativebit.fr changed their display name from NinjaTrappeur .: DECT 8711 to NinjaTrappeur. | 11:11:26 |
| 20 Aug 2023 |
|  Stéphan left the room. | 18:26:47 |
| 21 Aug 2023 |
| @infinisil:matrix.org | In reply to @infinisil:matrix.org
What would be the best way to integrate this into ofborg? I've thought of some options:
- Just add the check here as a
nix-build, but then CI would be super slow when Rust needs to be built
- Same as 1, but only make it run on the master branch, therefore generally avoiding problems with rebuilds, and this check is only important for new packages, which generally don't have to go to staging anyways
- Same as 1, but don't use dependencies from current Nixpkgs to build the Rust program, instead do a
fetchTarball for the latest stable NixOS release, which should definitely have Rust cached
- Put the version of the Rust check program into ofborg itself, such that it's not influenced by anything going on in Nixpkgs. This is the fastest, but least flexible
I think I know what I'll do now: Write the program in Rust, check the source into Nixpkgs (it's internal to Nixpkgs), make it be built by Hydra, make the nixpkgs-unstable channel be blocked on it succeeding to build on x86_64-linux, then have a GitHub Actions workflow fetch it from the nixpkgs-unstable channel and run it on every PR | 22:31:56 |
| @infinisil:matrix.org | The trade-off here is that I need a separate initial PR to get the program building in Hydra and wait for a nixpkgs-unstable update before it can actually start running in CI, but that's fine | 22:32:51 |
| @infinisil:matrix.org | From then on it should be very smooth sailing, could use any sort of caching in GitHub actions to speed it up further too (static build + github's action cache should be really fast) | 22:34:24 |
| @infinisil:matrix.org | So, no need to touch ofborg :) | 22:35:08 |
| @infinisil:matrix.org | (and I think this would be a great general pattern we should use more often) | 22:35:33 |
| @infinisil:matrix.org | Also this makes it more secure because CI won't have to build anything on its own. It does need to do a Nix evaluation, but it can do that with all the restrictions like pure eval, eval-only-mode, restricted eval, no IFD, etc. | 22:38:31 |
| @infinisil:matrix.org | * Also this makes it more secure because CI won't have to build anything on its own. It does need to do a Nix evaluation (for certain other bits of RFC 140), but it can do that with all the restrictions like pure eval, eval-only-mode, restricted eval, no IFD, etc. | 22:38:45 |
 raitobezarius | (I'm not sure if we can always use this pattern for anything, but it seems to be relevant for this one) | 22:38:54 |
| raitobezarius | (there's a value in how ofborg works at scale) | 22:39:02 |
| @infinisil:matrix.org | Redacted or Malformed Event | 22:39:13 |
| raitobezarius | In reply to @infinisil:matrix.org
Also this makes it more secure because CI won't have to build anything on its own. It does need to do a Nix evaluation (for certain other bits of RFC 140), but it can do that with all the restrictions like pure eval, eval-only-mode, restricted eval, no IFD, etc. CI as in GitHub Actions or Hydra here? | 22:39:31 |
| raitobezarius | I thought Hydra is building it or I misunderstood it | 22:39:40 |
