| 10 Apr 2022 |
 tomberek | Eg: better input tracking exposed, or lockless eval, attribute builds, and so forth. | 14:58:17 |
 tilpner | Lockless eval (with configurability over which inputs to unlock) sounds nice, though very at-odds with the current extremely hermetic evaluation.
Thank you very much for helping me narrow down my options, tomberek, and thank you cransom for describing how you do automatic deployments. I appreciate talking about this issue with someone else, after guessing about for a few days :)
| 15:00:41 |
|  @max.hausch:helsinki-systems.de joined the room. | 15:01:42 |
| tomberek | another possibility.... what is the thing that watches the jobsets and triggers a deployment to prod? | 15:02:57 |
| tilpner | In reply to @tomberek:matrix.org
another possibility.... what is the thing that watches the jobsets and triggers a deployment to prod? for now, it's just a small systemd timer that polls the most recent job output path with curl, but if this setup proves itself, I'm up for switching that for hydra's (dynamic) RunCommand plugin, or even listening for job completions with postgres listen/notify | 15:08:43 |
 cransom | i'd like to do some things like automatically follow nixos-21.11/release in my deploy jobs, except we (our app code, not nixpkgs) don't have adequate testing to make that an automatic feature. unattended production deployments without a good test gate isn't something i'll do. | 16:30:37 |
| cransom | the app code between prod/staging doesn't change, but that's a different beast when you get to doing deployments. there's nothing i can cache between staging/production because i deploy fully baked disk images into aws. if it was a generic disk image with different variables pulled in from aws metadata/user-data calls, that's possible. | 16:32:39 |
| tilpner | yes, I wouldn't be brave enough to do completely unattended deployments with an unlocked nixpkgs input. at least with application inputs, someone pushed the commit to the application repo that triggered the deployment, but changes to nixpkgs happen all day, even at night, and there'd be no way to react to a broken deployment :c | 16:40:54 |
| tilpner | * yes, I wouldn't be brave enough to do completely unattended deployments with an unlocked nixpkgs input. at least with application inputs, someone pushed the commit to the application repo that triggered the deployment and would probably notice breakage and fix it quickly, but changes to nixpkgs happen all day, even at night, and there'd be no way to react to a broken deployment :c | 16:41:29 |
| cransom | i'd be ok if we had a staging environment where those tests happend and if passed, it goes to production. i don't have that, but that's not a nix/nixpkgs problem. i'd love automatic deployment for any random security vulns/bug fixes that come up. | 16:45:59 |
 bitmapper | In reply to @ma27:nicht-so.sexy
I implemented https://github.com/NixOS/hydra/pull/919 for private projects a while ago i ended up just setting up a cloudflare firewall | 23:43:13 |
| 11 Apr 2022 |
 @ulrikstrid:matrix.org | Was there a PR fixing hydra on unstable? | 07:23:39 |
| @ulrikstrid:matrix.org | Maybe a better question, is there a nice way of getting hydra than just using the standard package in unstable? | 07:27:41 |
