| 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 |
| raitobezarius | Anyway, awesome :) | 22:42:07 |
| @infinisil:matrix.org | (unfortunately this does mean I'll have to rewrite https://github.com/NixOS/nixpkgs/pull/237439 to not require any Nix builds to do the check, doing everything in Rust instead) | 22:42:50 |
| @infinisil:matrix.org | (Well, not strictly required, but nice for security, not having to do Nix builds touching unreviewed code) | 22:44:13 |
| raitobezarius | Anything that doesn't do a nix-build is a win in my book | 22:45:03 |
| @infinisil:matrix.org | A bit sad because I just got nix-build -A tests.byName.nixpkgs working, feel free to try it out in the PR, it should verify everything about the pkgs/by-name directory :) | 22:45:15 |
| raitobezarius | hahaha :) | 22:45:22 |
| 23 Aug 2023 |
 @asymmetric:matrix.dapp.org.uk | Is OfBorg now successfully building on aarch64-darwin? | 15:07:57 |
| @asymmetric:matrix.dapp.org.uk | i remember some days ago the queue was advancing extremely slowly, with lots of timeouts | 15:08:54 |
 cole-h | It was always successful, the queue was just extremely long because the hardware is (relatively) less powerful, with less of those pieces of hardware for that queue | 15:10:04 |
| cole-h | For now, it seems we've caught up, but it may not stay that way for long. | 15:10:17 |
| cole-h | (So, I guess the answer is: yes -- for now x) | 15:11:00 |
