| 21 Jun 2021 |
 @grahamc:nixos.org | from a 30s look it isn't clear to me what actually is broken :grim | 15:53:25 |
 cransom | it feels like running an up to date hydra without the flake is a losing battle now. there are depends that slip in that don't make it to the nixos release or unstable package. | 16:31:09 |
 das_j | Yeah, always great to depend on a thing that's not even relesed let alone stable | 18:29:36 |
|  Taneb set their display name to Taneb. | 18:42:44 |
| 22 Jun 2021 |
| Taneb | Has there been any thought about making systemd-analyze security less upset by the Hydra units NixOS generates? | 08:38:09 |
| das_j | In reply to @taneb:hacksrus.uk
Has there been any thought about making systemd-analyze security less upset by the Hydra units NixOS generates? I can provide you with the units we use | 08:51:24 |
| das_j | well it's worse than I remembered:
hydra-check-space.service 9.6 UNSAFE 😨
hydra-compress-logs.service 9.6 UNSAFE 😨
hydra-evaluator.service 3.7 OK 🙂
hydra-notify.service 5.0 MEDIUM 😐
hydra-queue-runner.service 3.7 OK 🙂
hydra-server.service 3.7 OK 🙂
hydra-update-gc-roots.service 3.2 OK 🙂
prometheus-hydra-exporter.service 5.0 MEDIUM 😐
| 09:25:05 |
 Sandro | At least the emoji is not crying | 09:25:56 |
| Taneb | By default they're all 9.6 or 9.2 and... I really don't think they need to be | 10:01:04 |
| das_j | my units would probably be a lot better if I used CapabilityBoundingSet but I'm doing that with AppArmor because it's a lot less annoying. systemd doesn't detect that and therefore scores my units worse than they really are | 10:02:01 |
| @grahamc:nixos.org | it'd be great to improve them | 13:57:09 |
| @grahamc:nixos.org | anyone want to open a bug? | 13:57:35 |
| Taneb | https://github.com/NixOS/hydra/issues/977 | 14:49:20 |
 David Arnold | https://demo.hedgedoc.org/s/RO9YawHcY# | 20:03:32 |
| David Arnold | (ideas worth spreading?) | 20:03:51 |
 tomberek | In reply to @blaggacao:matrix.org
https://demo.hedgedoc.org/s/RO9YawHcY# I enjoyed this article. https://gregoryszorc.com/blog/2021/04/07/modern-ci-is-too-complex-and-misdirected/ I prefer to take it farther and even consider some batch data flows to be “indistinguishable from a build/CI system”. And it just so happens we have a powerful+flexible build system to utilize. | 20:13:50 |
| David Arnold | Thanks I'll put that in the intro! | 20:18:45 |
| David Arnold | Nice! That guy had the same feeling... I'd like for that article to be updated and instead of directing towards taskcluster, let them shiver in awe for what can be done with nix and a declarative State Machine + a declarative rules evaluator. | 20:23:48 |
| David Arnold | * Nice! That guy had the same feeling... I'd like for that article to be updated and instead of directing towards taskcluster, let them shiver in awe for what can be done with nix (the build DAG) and a declarative State Machine + a declarative rules evaluator. | 20:26:27 |
| David Arnold | AM I correct that we are slowly working towards fanning out builds within a DAG in nix? | 20:28:33 |
| David Arnold | * Am I correct that we are slowly working towards fanning out builds to remote builders within a DAG in nix? | 20:28:51 |
| David Arnold | * Am I correct that we are slowly working towards fanning out builds to remote builders within a build DAG in nix? | 20:28:57 |
| David Arnold | On the partial build side of things, where are we standing vs. bazel? Do we have already have composable partial rebuilds according to subtree changes? | 20:30:25 |
| David Arnold | I like the hydraJobs flake output special meaning, but I'd prefer it to be just jobs with a well informed interface. | 20:32:30 |
| David Arnold | * I like the hydraJobs flake output special meaning, but I'd prefer it to be just jobs with a well informed interface, that not only can return derivations but also talke to a remote resource (the state machine). Ideas? | 20:33:12 |
| David Arnold | Looks like there is potential for entanglement ... | 20:33:46 |
| David Arnold | * I like the hydraJobs flake output special meaning, but I'd prefer it to be just jobs with a well informed interface, that not only can return derivations but also talk to a remote resource (the state machine). Ideas? | 20:34:06 |
| tomberek | The granularity (or lack of) of some builds is the primary limitation for partial rebuilds. I’ve thought of a check-pointing mechanism for certain builds would be helpful, but I don’t know how to make it general enough. I’m also under the impression some PoCs have been done with bazel and a few others. | 20:38:25 |
| David Arnold | Thanks! I think flakes with their very strict input / output interfaces can be a milestone towards granularity. What do you think? | 20:42:58 |
| David Arnold | Also I'm breading over this addition:
## `taskcluster`? (pha, `nix` build DAG!)
Let's circle back to `taskcluster` as mentioned in the introductory rant. It seems that task cluster knows how to run a DAG of batch jobs. That's a bit of a different focus than a proper state machine, though. As for the build itself, we have our beloved `nix` primitives to resolve the build DAG.
| 20:43:32 |
