| 10 Apr 2022 |
 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 |
| tilpner | which is of course also an impurity, so I don't know if it has a chance of being merged | 14:16:12 |
| tilpner | hmm, maybe not actually an impurity, as the same -A foo will always lead to the same result, it's just that hydra will pass different -A values... | 14:17:08 |
| tilpner | you make a good point, depending on actual branches names is annoyingly brittle. passing in a tag (or attribute name) would work regardless of git branch and also support evaluation if the input isn't being fetched from git | 14:18:43 |
| tomberek | that's just because you only intend to turn some jobs on/off, but you COULD make that substantially change behavior and users would have no idea. And the behavior of the same commit will change over time. | 14:18:57 |
| tomberek | i think the .version or .branch file is the easiest way to smuggle the branch name in | 14:19:35 |
| tomberek | you can make your push-to-deployment only depend on the job that matters, not the entire jobset | 14:25:24 |
| tilpner | okay, you've convinced me that source control information should never reach the build, so instead I'd need to communicate a tag/mode/variant to the jobset | 14:26:11 |
| tilpner | adding that file to the repo would work, of course, but then you lose the ability of simply pushing the staging branch to the production branch whenever it's ready | 14:27:59 |
| tilpner | who determines whether #1143 has a chance of being merged? | 14:28:28 |
| tilpner | (I'm happy to run a patched hydra, but if the answer is a "this will never be accepted", I'll need to keep looking for a different way to make this work) | 14:29:11 |
| tomberek | wait..... if you have a flow where you push from staging branch to production.... the builds should already be cached | 14:33:08 |
| tomberek | if you built on staging..... .cache it.... then production builds are instant | 14:33:27 |
| tilpner | true, and in a way it makes sense to test if production builds before allowing it for staging, but staging pushes are going to be much more frequent than production pushes, so that's still a lot of wasted builds | 14:37:42 |
| tilpner | * true, and in a way it makes sense to test if production builds before allowing it for staging, but staging pushes are going to be much more frequent than production pushes, so that's still a lot of wasted time, waiting for production builds to finish, just to deploy staging | 14:39:30 |
| tomberek | depend on the job to complete, not the jobset | 14:41:49 |
