<clever>
thats the type "githubpulls" in the spec.json
<clever>
when both halves are put together, hydra will create a new jobset for every PR, and post the status back to the commit that is at the tip of the branch
<clever>
it uses the current revision of the input named on line 64 to know which github and which rev
<clever>
any job matching that regex gets posted to github as a status
<clever>
LnL: and line 62 contains a piece of regex, that must match the project:jobset:job string
<clever>
LnL: the github token on line 60 needs repo:status to post the travis checks, and its also used to greatly increase the ratelimiting for the PR data
<clever>
at the same time it polls github for changes to given branches
<clever>
for this half of it, adding a build input of type "githubpulls" causes hydra to query the PR list every time its checking for changes to the inputs
<clever>
LnL: that jobset must contain a single build called jobsets, which returns more json, a list of the same structure, which will configure all other jobsets
<clever>
LnL: hydra will fetch that json, and use it to create a jobset called .jobsets
<clever>
LnL: you setup the url to a repo like this, and give it a relative path like "toxvpn/spec.json" (very similiar to setting the release.nix stuff)
<clever>
infinisil: i think the expense summary is only for prs.nix.gsc.io?
<clever>
infinisil: a painful amount :P
<clever>
LnL: same to view the review statuses
<clever>
LnL: for anything more complex like a special word a certain user has to say, it would need some changes to the perl in hydra
<clever>
LnL: that could then easily be implemented with the nix logic i have in my hydra-configs repo
<clever>
LnL: of note, the milestone and assignees appear to be available in the json, so you could have a "magic" milestone that hydra will filter the PR's on
<clever>
gnuhurd, sphalerite: currently, all services have to be rewritten by hand, it cant translate the existing systemd.services definitions over
<clever>
LnL: i have since set it up on 2 hydras and helped a 3rd person set it up
<clever>
LnL: and that whole process is done inside a pure nix build
<clever>
LnL: and hydra will then re-configure itself
<clever>
LnL: using the declarative jobset stuff, hydra can pass you some JSON describing all PR's, you must then return some JSON describing all jobsets
<clever>
brb
<clever>
grahamc: yeah, i previously said that assuming nix and the sandbox logic is 100% perfect, the only other threats i can think of are people abusing cache.nixos.org to host content we dont want to host
<clever>
if we ignore sandbox/kernel level exploits
<clever>
grahamc: such as?, the only things i can think of are weird network requests (if you claim to have a hash), and chewing up cpu/ram
<clever>
bendlas: i think this is also why sudo based travis runs in a full vm, and non-sudo travis runs as a container
<clever>
bendlas: so only kernel exploits are a threat for non-fixed-output paths
<clever>
bendlas: if you turn on a sandbox in nix, it cant read / or even access the network
<clever>
infinisil: hydra has no way to limit that per jobset right now
<clever>
and end-users only get that output if they ran the same malicious script under nix-build
<clever>
bendlas: if the container logic does its job, then the scripts output merely gets saved to cache.nixos.org and it does no real harm
<clever>
LnL: the bigger risk i can see, is people opening PR's that download things, and abusing cache.nixos.org as a mirror for whatever they want, of any size
<clever>
aupiff: only when using nix-shell is the env properly modified to make things work
<clever>
aupiff: you should open a nix-shell that has the nixpkgs clang in its PATH
<clever>
LnL: and at that point, nix would have just built the thing on the end-users machine anyways
<clever>
LnL: if nix is trusted 100%, then only users running the "malicious" nix expression will get the cached build
<clever>
infinisil: the current github status plugin in hydra doesnt produce the right output to make it a sensible status hook
<clever>
ive only used the nixos module, and nixos should never be ran from nixpkgs-unstable
<clever>
eacameron: dang, that makes it much harder to share the logs for debug purposes
<clever>
eacameron: do you know if the journal logs that letsencrypt makes on nixos contain any secrets?
<clever>
Phillemann: after the build is done, nix will check for every build input in your output (by grepping for the storepaths), and any paths it finds become runtime dependencies
<clever>
Lisanna: looks like $buildFlags is the best option you have
<clever>
nwuensche: double-check what the i command says about it
<clever>
nwuensche: i think so
<clever>
dtzWill: there is also a related problem that cant easily be fixed
<clever>
and nix wants to haul along the entire uncompressed copy of nixos
<clever>
but i needed to refer to a path that will exist inside the squashfs, on the kernel cmdline
<clever>
the last time i used that, i squashfs'd an entire nixos up, then jammed that into an initrd
<clever>
but it will have bar's absolute path
<clever>
so i can make a config file that does "foo=${builtins.unsafeDiscardStringContext bar}", and that config wont depend on bar
<clever>
that strips all context from a string
<clever>
builtins.unsafeDiscardStringContext is also a fun function
<clever>
yeah
<clever>
ah
<clever>
then you'll know you cheated
<clever>
so if you cheat, the files just wont exist
<clever>
that will enforce you to only access things that are properly defined as build inputs
<clever>
also, you should really build with sandboxing on
<clever>
and only the build-time deps are looked for in the output
<clever>
dtzWill: and if any string with context is pased to derivation, they become build-time deps
<clever>
dtzWill: the builtins.derivation function creates a string (the output path) that depends on the derivation
<clever>
dtzWill: every string in nix has some magic context on it, the dependencies of the string
<clever>
dtzWill: if you hard-code a storepath as a string, it wont
<clever>
dtzWill: but only if you got those paths via a derivation
<clever>
dtzWill: yes
<clever>
moesasji: this creates 3 bash scripts, and then i can just do something like environment.systemPackages = [ (pkgs.callPackage ./util.nix {}) ];