| 10 Apr 2022 |
 @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 |
| tilpner | In reply to @casey:hubns.net
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 yes, the "legacy" mode seems a lot better suited to what I need, but I started with a flake because legacy usually implies it's not going to be supported forever :/ | 13:57:40 |
| cransom | I agree. but also, flakes have been experimental for how long and I haven't seen an announcement as to when flakes won't be experimental. | 13:58:53 |
| cransom | flakes are there to dismiss nix-channel, which for hydra and deployment like this, it's not using channels. | 13:59:40 |
| cransom | i've been on the fence about moving to flakes for a couple years for work and I don't see the upside yet. it's a moving target. for personal projects, thats ok. if i have to subject the teams/company to it, it needs to be stable. so i would say that the non flake method shouldn't be called legacy, but stable. | 14:01:39 |
| tomberek | Or.... just build both jobs in both cases.... doesn't seem too onerous. | 14:07:20 |
| tomberek | If just starting out, i'd say adopting flakes is a good idea. If you have a large Nix codebase already, it's okay to delay a bit longer. It's really a question of how much "novelty budget" you have. Kinda like Python2/3 transition: it's painful, but eventually unavoidable. | 14:08:27 |
| tilpner | I already have a few flakes, but (though I haven't tried it yet) I hope I can use flake-compat to use them even in legacy mode | 14:11:28 |
| tomberek | back to the problem.... the trouble is that branch names and tags are not reproducible, so it's not something normally included into an evaluation | 14:11:30 |
| tomberek | eg: should a specific git commit checkout behave differently based on what branches and tags exist due to the git server it happens to live on? | 14:12:18 |
| tilpner | And yes, though building both variants works, there are actually two applications, and building just one variant for it takes a few minutes, so eliminating unused variants could decrease valuable push-to-deployed latencies | 14:12:35 |
| tilpner | In reply to @tomberek:matrix.org
eg: should a specific git commit checkout behave differently based on what branches and tags exist due to the git server it happens to live on? Perhaps not in an unchecked universal way, but it would certainly make this task easier | 14:14:11 |
| tilpner | ... how hard would it be to make hydra expose the branch name to builds? | 14:14:55 |
| tomberek | yeah.... i'm thinking.... you can have something in the production branch, a file like .version (nixpkgs has one) | 14:15:04 |
| tilpner | (alternatively, this is solved-ish by https://github.com/NixOS/hydra/pull/1143) | 14:15:51 |
| tomberek | the problem is that now the branch name leaks into builds... and changes behavior... the whole point of flakes is that it must be reproducible, and the branch name leaking in means even if I'm on the same commit as you, i may get different behavior. | 14:15:52 |
