| 21 Aug 2023 |
@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 |
@asymmetric:matrix.dapp.org.uk | ok. asking because i'm trying to document a list of supported platform tiers, and wondering where aarch64-darwin should be there.
From the perspective of OfBorg (and if you have the context, the POV of Hydra as well), do you agree with the following:
Tier 1
x86_64-linux-gnu using gcc
Tier 2
aarch64-linux using gcc
aarch64-darwin using clang
x86_64-darwin using clang
| 15:15:17 |
@asymmetric:matrix.dapp.org.uk | * ok. asking because i'm trying to document a list of supported platform tiers, and wondering where aarch64-darwin should be there.
From the perspective of OfBorg (and if you have the context, the POV of Hydra as well), do you agree with the following:
Tier 1
x86_64-linux-gnu using gcc
Tier 2
aarch64-linux using gcc
aarch64-darwin using clang
x86_64-darwin using clang
| 15:15:27 |
cole-h | I don't know the definitions of "tier X", so I can't really comment. | 15:15:49 |
cole-h | From my perspective, they're all "best effort", with most of that "effort" concentrated on x86_64-linux-gnu :P | 15:16:10 |
@asymmetric:matrix.dapp.org.uk | OK, that's more or less how I meant those tiers to be understood | 15:16:30 |
@asymmetric:matrix.dapp.org.uk | But for a formal definition (which I don't think is being followed), see this merged RFC https://github.com/7c6f434c/rfcs/blob/platform-support-tiers/rfcs/0046-platform-support-tiers.md | 15:17:16 |
@asymmetric:matrix.dapp.org.uk | * But for a formal definition (which I don't think is being followed), see this merged RFC https://github.com/NixOS/rfcs/pull/46 | 15:17:36 |
cole-h | At least for ofborg, we do have more support for aarch64-linux as opposed to any of the darwin systems (mostly due to it being easier and cheaper to get high-powered machines for our builds) | 15:17:50 |
cole-h | So, only taking ofborg's support into account, I'd order the "effort" for each platform as x86_64-linux > aarch64-linux >>>>>>> aarch64-darwin > x86_64-darwin | 15:18:49 |
Lily Foster | Tbh my ofborg builds often finish on aarch64-linux box first, which is impressive given all of the runners are on the same massive community builder box | 15:24:39 |
cole-h | Ampere is super stronk. And the x86_64-linux builders also run the evals (which are expensive), which may contribute to their relative slowness :P | 15:26:11 |
Lily Foster | Oof, I didn't realize those were co-located on the same boxen 👀 | 15:27:35 |