| 17 Aug 2023 |
 @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 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 |
| @infinisil:matrix.org | GitHub Actions | 22:39:46 |
| @infinisil:matrix.org | So Hydra will only build committed things, while GitHub Actions avoids building any uncommitted things | 22:40:02 |
| raitobezarius | Ah yes, I would say, it's safer or more secure in the sense of all our "build sandbox" parameters | 22:40:40 |
| raitobezarius | Because our machine identity story is not super good for CI for Hydra | 22:40:51 |
| raitobezarius | But I don't want to depend on GH Actions neither for that, but they do have proper machine identity and provenance | 22:41:09 |
| raitobezarius | (which is an example of CI security property that is desirable) | 22:41:43 |
| @infinisil:matrix.org | Yeah | 22:41:44 |
