| 10 Apr 2022 |
 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 |
| @ulrikstrid:matrix.org | I have commit rights/own the repo(s) I want to use this on | 13:01:24 |
| tilpner | yes, you can specify the branch while fetching an input | 13:01:35 |
| @ulrikstrid:matrix.org | Okay, nice 👌 I'll see if I can find some time this evening to play with it | 13:02:23 |
| tilpner | I have an application flake with one derivation for building in staging mode and one for building in production mode. This flake exists on two different branches (you guessed it, staging and production), which I'd both like to deploy automatically. It's only a slight annoyance, but hydra build both branches in both modes, even though the staging build of the production branch and the production build of the staging branch won't be needed. If I could pass arguments to a flake jobset, I could conditionally present a different hydraJobs attrset, but AFAIK there's no way to pass arguments to a flake jobset. Is there an easy workaround here? | 13:14:00 |
| tilpner | * I have an application flake with one derivation for building in staging mode and one for building in production mode. This flake exists on two different branches (you guessed it, staging and production), which I'd both like to deploy automatically. It's only a slight annoyance, but hydra builds both branches in both modes, even though the staging build of the production branch and the production build of the staging branch won't be needed. If I could pass arguments to a flake jobset, I could conditionally present a different hydraJobs attrset, but AFAIK there's no way to pass arguments to a flake jobset. Is there an easy workaround here? | 13:19:31 |
| tomberek | no, no inputs from the outside. But a flake can do something like check the existence or contents of another file: builtins.pathExists. Perhaps something like hydraJobs = if builtins.pathExists x then import x self else null; or something like that | 13:22:09 |
| tilpner | In reply to @tomberek:matrix.org
no, no inputs from the outside. But a flake can do something like check the existence or contents of another file: builtins.pathExists. Perhaps something like hydraJobs = if builtins.pathExists x then import x self else null; or something like that surely this only allows checking the existence of paths inside the flake? I don't want the branches to diverge (also to avoid any git merge pain), just have production lag behind staging for a few days | 13:25:45 |
| tomberek | perhaps this is what i don't understand: "but hydra builds both branches in both modes" | 13:35:27 |
| tilpner | In reply to @tomberek:matrix.org
perhaps this is what i don't understand: "but hydra builds both branches in both modes" to make hydra build and test both branches, I have to create two jobsets, one for each branch. the production jobset still has two jobs (because it doesn't know it's going to be used for production),one for a production build and one for a staging build. but only the production build of the production jobset is going to be deployed, the staging build is unnecessary | 13:38:11 |
| tilpner | but maybe I'm doing this all wrong, I'm mostly guessing how these parts should fit together, there's not that much information out there for automatic application deployment with hydra :) | 13:39:13 |
| tomberek | you'd need to do something conditional on the branch... there may be a few ways of doing that,,, but sadly even git doesn't even persist branch information (essentially because they are mutable) | 13:51:13 |
 cransom | i do deployments in hydra, but there's no flake involved. hydra doesn't know the difference between production and staging, they are all just different environments being fed by different branches. the jobset builder creates a jobset for each environment where the inputs are specific to that branch/env | 13:53:21 |
| tomberek | another possibility: create a flake that has inputs:
inputs.production.url = "github:org/repo/production";
inputs.staging.url = "github:org/repo/staging":
and go from there
| 13:54:56 |
| tilpner | In reply to @tomberek:matrix.org
another possibility: create a flake that has inputs:
inputs.production.url = "github:org/repo/production";
inputs.staging.url = "github:org/repo/staging":
and go from there
I have considered that, but then wouldn't I have to update those inputs and push an updated flake.lock, in order for hydra to evaluate the updated branches? | 13:56:14 |
