Hydra | 380 Members | |
| 110 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Aug 2022 | ||
| I haven't used Hydra much and have a question to see whether it might be a suitable tool for my usecase. I maintain a repository which defines some FPGA-targets for an embedded OS and I am providing pre-built FPGA bitstreams for these targets, so people don't have to install the heavyweight proprietary FPGA toolchains (>= 50GB binary blob) themselves. I'm already building all of this with Nix, but using regular CI infrastructure like GitHub Actions or TravisCI to automate this is infeasible (can't redistribute the binary blob and it exceeds CI resource limitations). If I were to build this with Hydra, can I
| 09:05:59 | |
| 09:31:52 | |
| 1. maybe/sort of yes. we build stuff like displaylink on our internal hydra, where you need to download the zip manually and agree to the license. 2. sure. hydra comes with a binary cache, but barely anyone uses it. you could just have a hook to only copy the bitstreams or use hydra-support stuff, to offer downloads. | 09:31:58 | |
In reply to @andreas.schraegle:helsinki-systems.deWe should finally implement a setting to disable the binary cache | 09:32:33 | |
| What about adding the toolchain as an impure path? That way it never ends up in the store unless a derivation explicitly copies it in | 09:32:56 | |
| well, I use the binary cache because plotting a nix-serve next to it is not really any different | 09:33:23 | |
In reply to @sandro:supersandro.deI didn't say I wanted to remove it (right now), just having an option to hide the option in the UI and to serve 404s instead of NARs | 09:33:55 | |
In reply to @linus:schreibt.jetzt( extra-sandbox-paths nix option, see man nix.conf) | 09:34:00 | |
The requireFile approach is better for reproducibility, but with a greater risk of accidentally redistributing it, while the extra-sandbox-paths approach means you have extra steps to set up the build environment | 09:35:12 | |
| Cool, thanks for these hints! I wouldn't have known where to start. I'll try to set up a Hydra and see how far I come :) | 10:19:28 | |
| Linux Hackerman: I was under the impression that impure paths were kind of a hack, no? Would you be suggesting that I install the toolchain elsewhere on that system and make it accessible to the build environment. One thing I'd like to retain is the ability for others to potentially use the built artifacts in a binary-cache style. That should work even if I don't redistribute the toolchain, given it's only a build-time dependency and is not referenced in the final realized derivation. Not sure how that would play with impure paths. | 10:23:33 | |
| * Linux Hackerman: I was under the impression that impure paths were kind of a hack, no? Would you be suggesting that I install the toolchain elsewhere on that system and make it accessible to the build environment? One thing I'd like to retain is the ability for others to potentially use the built artifacts in a binary-cache style. That should work even if I don't redistribute the toolchain, given it's only a build-time dependency and is not referenced in the final realized derivation. Not sure how that would play with impure paths. | 10:23:49 | |
| I think for now I can just operate the Hydra behind a firewall and manually copy the final artifacts somewhere else, isn't really a high-frequency deployment situation. But yeah, disabling the binary cache would be a great feature. | 10:24:47 | |
Yes, exactly
As long as the artifacts don't need the toolchain present to work, that should be fine | 10:25:11 | |
| You can also combine the impure path with a system feature which is required by the derivations, so people (and hydra) don't "accidentally" try to build them on a system that doesn't have the toolchain set up appropriately | 10:25:51 | |
| And with impure-paths you can literally use a binary cache as opposed to just binary-cache style ;) | 10:26:18 | |
| Hm, that does indeed sound like a rather elegant solution. Forces users to install the toolchains to a fixed path though, if they want to obtain the (input-hash) identical derivations though, right? | 10:27:04 | |
| No, if they use the binary cache they can get them from there | 10:27:29 | |
| (but yes if they want to build them locally) | 10:27:41 | |
| Thanks for this advice! I'll see how I can make it work :D | 10:29:52 | |
| 17:03:16 | ||
| 17:25:07 | ||
+1 for extra-sandbox-paths, also check out buildFHSUserEnv for running binaries that expect FHS paths to be present. Here's an example environment for Vivado https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/artiq-fast/vivado.nix | 17:31:01 | |
Also, has anyone figured out a good way to do proper CI/CD with Hydra using flakes? I have several repositories, each with their own flake, and then a central flake that pulls them in and defines the hydraJobs. With legacy builds it was easy - just specify a repository as an input, and as long as the revision isn't pinned then any new commits will trigger a build. In addition to the restrictive lock flags Hydra uses (https://github.com/NixOS/hydra/issues/1160), it seems that flake support is just... bad. e.g. flake inputs aren't even recorded in Hydra's DB. I've been working on patches to Hydra to allow "unlocked" flakes, but that's a good chunk of work and I'm wondering if I can hack something else together more easily. | 17:38:11 | |
One idea I've had is to have a separate jobset that just does something like a nix flake update and copies the flake.nix and flake.lock to the output, and then use that flake as the input for the real jobset, but I'm not sure if that's doable | 17:40:03 | |
| And the absolute hackiest idea I've had is to put the flake in a local file on the server and make a cron job that updates it periodically | 17:42:07 | |
| i don't know if i'm up to date with all the methods, but i think the current general practice was something like your cron job - another task that runs nix flake update, commits, and pushes. | 17:44:50 | |
| that's a bummer :/ talk about a messy git history | 17:47:57 | |
| 20:18:07 | ||
| 22:09:00 | ||