visual presentation of builds

[vcunat]

It would probably be nicer to have build status of explicit runs in the CI box as well (like the eval checks), especially as more platforms are planned.

[Mic92]

Also the full log would be interesting in case of a failure.

[grahamc]

I'm a bit anxious about this, given that they're running on random computers. I'm somewhat worried about giving up too much information, as it could be used maliciously. Thoughts?

[vcunat]

People shouldn't run these without nix sandboxing. Otherwise I can't see any risks directly, but I haven't given it too much thought so far.

[grahamc]

Unfortunately Darwin doesn’t have adequate sandboxing at this time, plus possible issues around the fairly loose sandbox for fixed output drvs.

…

On Sat, Dec 9, 2017 at 11:33 AM Vladimír Čunát ***@***.***> wrote: People shouldn't run these without nix sandboxing. Otherwise I can't see any risks directly, but I haven't given it too much thought so far. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/grahamc/ofborg/issues/7#issuecomment-350486356>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAErrO66KjXnJLAD2BURGL9s9NA6mGQKks5s-rZqgaJpZM4QqckY> .

[Mic92]

From a security perspective, how does a shorter log help from preventing confidential information?

[LnL7]

Actually sandboxing works fine with 1.12 locally now.

[grahamc]

Going back to the original key point of this issue:

It would probably be nicer to have build status of explicit runs in the CI box as well (like the eval checks), especially as more platforms are planned.

I don't want to do this, because the green check should be sacred and a "sure thing" for any valid PR. Any potential for unnecessarily causing it to go to a red X should be avoided. This is to make the green check be a strong promise that the code is good, and a red X a guarantee that something is wrong.

Right now, we can't make that promise / guarantee due to periodic issues with aarch64 support or darwin sandboxing. Failed build results still require examination to determine if they're valid issues or not.

[grahamc]

BTW I have Mac sandboxing instructions at https://github.com/grahamc/ofborg/wiki/Operating-a-Builder#macs-and-sandboxing now

[grahamc]

Many of the builders are now streaming full logs back to the server. This is configurable per builder, so some builds will still not provide full logs (https://github.com/NixOS/ofborg/blob/released/ofborg/src/config.rs#L27, https://github.com/NixOS/ofborg/blob/released/ofborg/src/tasks/build.rs#L275)

1. It is possible to see a build's logs while they happen by viewing: https://nix.samueldr.com/temp/?key=nixos/nixpkgs.12345 where 12345 is the PR number.
2. This live-viewer will load scroll-back from the log server, for example: https://logs.nix.gsc.io/logs/nixos/nixpkgs.34107/7db796d3-4da3-4ac5-bc31-55655a2a6ecb but only if you load the log viewer while the build runs.
3. The log server exposes an "API" for enumerating attempt logs: https://logs.nix.gsc.io/logs/nixos/nixpkgs.34107 and soon the log viewer will also be using this API (Ask the log server for a list of attempts per routing key ofborg-viewer#2) so you can reload the log viewer page long after the build has finished and see the logs.

Once part 3 is done, I'll automatically provide links to the build output on a PR when the bot is called.

I have to say, a huge thank you to @samueldr for implementing this log viewer for me -- you have been a tremendous help.

[grahamc]

Full logs are now available.