| 9 Apr 2022 |
Amanda (she/her) | You probably don't want stuff changing it from under you for automatic deployments, see: node and the recent "protestware" package updates | 13:52:08 |
Amanda (she/her) | * You probably don't want stuff changing out from under you for automatic deployments, see: node and the recent "protestware" package updates | 13:52:25 |
tilpner | I have two flakes, one for the system definitions, and one for an application. If I push a new commit to the application, I'd like hydra to build and check it, and then deploy it | 13:53:17 |
tilpner | That would work fine even in flakes mode, if it were a monorepo. As both repos are under my control, I'm not worried about malicious package updates, though of course these automatic updates should be selective | 13:54:50 |
tilpner | I suppose I could configure hydra to execute a script after a build of the application repo finishes, which pushes a commit to the systems repo to trigger a deployment of that | 13:57:20 |
tilpner | (https://github.com/NixOS/hydra/pull/1103 would be neat for that) | 13:59:03 |
tilpner | I don't need changes to the application to trigger rebuilds of the system in this instance, as I can poll-deploy the latest evaluation of the application to a separate nix profile and restart the corresponding systemd service. But that's not a general solution, and wouldn't support e.g. keeping a nixos module for the application in the application flake, because the system flake jobset couldn't automatically update itself to use that new module | 14:06:19 |
tilpner | (Yes, keeping and automatically applying a nixos module from an application module is a security issue if different sets of people have access to the application and system repositories) | 14:07:39 |
tilpner | * (Yes, automatically applying a nixos module from an application module is a security issue if different sets of people have access to the application and system repositories) | 14:15:18 |
@grahamc:nixos.org | we should merge that PR | 18:58:40 |
| 10 Apr 2022 |
@ulrikstrid:matrix.org | If I want to start playing with hydra, is it best to setup everything on the same machine and then add more builders later? | 12:47:49 |
tilpner | I don't know about best, but running hydra without remote builders is perfectly fine | 12:48:33 |
@ulrikstrid:matrix.org | Best was the wrong word, easiest is what I was looking for 😅 | 12:49:16 |
@ulrikstrid:matrix.org | Maybe another stupid question, can I have the project config separate from the repo I'm building? | 12:49:56 |
tilpner | that said, I do have localhost registered as a remote builder, just... a local remote builder :P | 12:50:31 |
tilpner | what do you mean by project config? | 12:51:32 |
@ulrikstrid:matrix.org | What and how to build a project, I'm not sure about the wording of hydra | 12:52:06 |
tilpner | The "what projects to build" can be configured declaratively in a jobsets repository: https://hydra.nixos.org/build/172143314/download/1/hydra/plugins/declarative-projects.html | 12:53:59 |
tilpner | But I don't think that's what you meant, as the non-declarative jobset configuration wouldn't be part of the repo anyway | 12:54:20 |
@ulrikstrid:matrix.org | So to simplify: can I build any repo with a nix configuration? | 12:55:08 |
@ulrikstrid:matrix.org | And, does the repo have to know about hydra? | 12:55:30 |
tilpner | No, the repositories don't have to know about hydra | 12:56:11 |
tilpner | (but it might be more direct if they do, as otherwise you may have to specify hydraJobs in a separate repo which pulls in the first repo) | 12:57:47 |
@ulrikstrid:matrix.org | I basically want to play with hydra for some repos before committing to it | 12:58:26 |
tilpner | before committing to hydra, or before committing to the repos? | 12:58:55 |
@ulrikstrid:matrix.org | Especially if I want to introduce it at work | 12:58:59 |
@ulrikstrid:matrix.org | Before committing to hydra | 12:59:03 |
tilpner | you can always fork the repo and register the fork with hydra? | 12:59:40 |
tomberek | Ulrik Strid: sure... you can create an "external expression" where the Nix lives apart from the source code. As opposed to an "internal expression" which would live in the same repo. | 13:00:08 |
@ulrikstrid:matrix.org | Actually, can I do it at any branch? | 13:00:16 |