| 14 Feb 2022 |
 @grahamc:nixos.org | one tricky bit of that is of course the process breakdown of hydra-evaulator calling hydra-evaluate-jobset calling hydra-eval-jobs, and potentially each of these could feasibly contain their own exporter, which would also be weird | 14:27:52 |
 das_j | What about this: The main daemon opens a fd for its subprocesses (FD 5 or something), and the subprocesses write their metrics there, maybe as kv pairs? Would be shitty but better than nothing | 14:29:04 |
| das_j | The main process can then collect these and serve them | 14:29:27 |
| @grahamc:nixos.org | I've tried to do that for ofborg in the past but was sort of a mess | 14:29:31 |
| @grahamc:nixos.org | but that was quite a bit more complicated | 14:29:55 |
| das_j | or each component just writes its stats into the main db and we scrape from there | 14:29:59 |
| @grahamc:nixos.org | so it could very well work here | 14:30:00 |
|  @pedrohlc:mozilla.org joined the room. | 15:13:45 |
| 15 Feb 2022 |
|  @packetgrill:automattic.com joined the room. | 13:32:31 |
 Linux Hackerman | So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a hyra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? | 16:45:49 |
| Linux Hackerman | * So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? | 16:45:55 |
| Linux Hackerman | Aah, apparently gen_random_uuid() is built into postgres starting from 13.x | 16:49:57 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? Ah if you're touching it anyway (I know people love when I say that - could you replace --set HYDRA_RELEASE ${version} \ with --set-default HYDRA_RELEASE ${version} \? I don't think it's worth its own PR | 16:51:14 |
| Linux Hackerman | lol | 16:51:31 |
| Linux Hackerman | yeah can do that | 16:51:37 |
| das_j | thanks ;) | 16:51:42 |
 Rick (Mindavi) | In reply to @linus.heckemann:matrix.mayflower.de
So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? Thanks for looking into that. | 17:08:44 |
| Linux Hackerman | thanks for starting the work, I picked your commit as a base :) | 17:09:00 |
| Linux Hackerman | das_j: hm, why exactly should that be --set-default? Changing that to something other than the running package seems weird. | 17:14:35 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
das_j: hm, why exactly should that be --set-default? Changing that to something other than the running package seems weird. I'm overriding the src of the package locally and the postPatch is not affected by that override | 17:15:03 |
| Linux Hackerman | aah fair | 17:16:20 |
| Linux Hackerman | das_j: Rick (Mindavi): would you care to be maintainers as well? With https://github.com/NixOS/nixpkgs/pull/158948 it doesn't currently have any maintainers. | 19:01:50 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
das_j: Rick (Mindavi): would you care to be maintainers as well? With https://github.com/NixOS/nixpkgs/pull/158948 it doesn't currently have any maintainers. Yeah why not. Will probably not give me substantially more GH notifications 🤷 | 19:05:31 |
| Rick (Mindavi) | I'm running it from nixpkgs anyway, so don't mind reviewing now and then | 19:08:40 |
| Linux Hackerman | sweet, so the package goes from 1 to 0 to 3 maintainers :D | 19:08:43 |
| Linux Hackerman | Hm, I've been trying to mix lovesegfault's changes from https://github.com/NixOS/nixpkgs/pull/157072 in as well. Not sure if this is actually something we should do or not though | 19:27:08 |
| Linux Hackerman | I think it does make sense to have a single version of hydra in nixpkgs. And I think the hydra package in nixpkgs is a bit "second-class" given that upstream development and the hno deployment use flakes. | 19:31:13 |
| Linux Hackerman | Any opinions? | 19:31:33 |
| Linux Hackerman | Though I'm pretty sure that if we have only a single hydra package, we should also only have a single hydra test :) | 19:31:50 |
| Linux Hackerman | * Though I'm pretty sure that if we have only a single hydra package, we should also only have a single hydra test, so if I do pull in lovesegfault's changes I'll also add that :) | 19:33:27 |
