!zghijEASpYQWYFzriI:nixos.org

Hydra

386 Members
109 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
14 Aug 2022
@k900:0upti.meK900image.png
Download image.png
18:17:59
@weebsorceress:matrix.org@weebsorceress:matrix.org joined the room.19:05:52
@weebsorceress:matrix.org@weebsorceress:matrix.org left the room.19:08:50
15 Aug 2022
@ulrikstrid:matrix.org@ulrikstrid:matrix.orgIs this the only thing I need to set to get remote cache upload working for hydra? https://github.com/NixOS/nixos-org-configurations/blob/master/delft/hydra.nix#L3311:43:29
@ulrikstrid:matrix.org@ulrikstrid:matrix.orgAnd the aws stuff obviously11:43:51
@amanda:camnet.siteAmanda (she/her)That's all I needed for my minio cache, yeah14:37:29
@replaycoding_:matrix.orgReplayCoding changed their display name from ReplayCoding (she/her) to ReplayCoding.16:24:36
@h7x4:nani.wtfh7x4 set a profile picture.17:21:10
@pederbs:pvv.ntnu.nopbsds changed their display name from pederbs to pbsds.23:19:28
16 Aug 2022
@k900:0upti.meK900
In reply to @k900:0upti.me
OK whomst do I poke here to get https://github.com/NixOS/hydra/pull/1243 merged
Bump
18:42:44
@janne.hess:helsinki-systems.dedas_j
In reply to @k900:0upti.me
Bump
ajs124
18:42:56
@-=h0p3=-:matrix.org-=h0p3=- joined the room.21:45:16
17 Aug 2022
@leons:is.currently.online@leons:is.currently.online joined the room.08:55:37
@leons:is.currently.online@leons:is.currently.online

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

  1. manually add the proprietary toolchain to the build system's nix-store as a garbage collector root and have Hydra use that for its builds, and
  2. instruct Hydra to not offer / publish the proprietary toolchain itself? While it should be perfectly legal to compile a bitstream and redistribute that final artifact, I am not allowed to redistribute the toolchain itself. I do want to make the final artifacts available somewhere, although that doesn't have to be through Hydra directly.
09:05:59
@sandro:supersandro.deSandro
  1. required file
  2. not easily
09:31:52
@andreas.schraegle:helsinki-systems.deajs1241. 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
@janne.hess:helsinki-systems.dedas_j
In reply to @andreas.schraegle:helsinki-systems.de
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.
We should finally implement a setting to disable the binary cache
09:32:33
@linus:schreibt.jetzt@linus:schreibt.jetztWhat about adding the toolchain as an impure path? That way it never ends up in the store unless a derivation explicitly copies it in09:32:56
@sandro:supersandro.deSandrowell, I use the binary cache because plotting a nix-serve next to it is not really any different 09:33:23
@janne.hess:helsinki-systems.dedas_j
In reply to @sandro:supersandro.de
well, I use the binary cache because plotting a nix-serve next to it is not really any different
I 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
@linus:schreibt.jetzt@linus:schreibt.jetzt
In reply to @linus:schreibt.jetzt
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
(extra-sandbox-paths nix option, see man nix.conf)
09:34:00
@linus:schreibt.jetzt@linus:schreibt.jetzt 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
@leons:is.currently.online@leons:is.currently.onlineCool, 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
@leons:is.currently.online@leons:is.currently.online 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
@leons:is.currently.online@leons:is.currently.online * 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
@leons:is.currently.online@leons:is.currently.onlineI 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
@linus:schreibt.jetzt@linus:schreibt.jetzt

Would you be suggesting that I install the toolchain elsewhere on that system and make it accessible to the build environment

Yes, exactly

One thing I'd like to retain is the ability for others to potentially use the built artifacts in a binary-cache style.

As long as the artifacts don't need the toolchain present to work, that should be fine

10:25:11

Show newer messages


Back to Room ListRoom Version: 6