<MichaelRaskin>
1. Why not copy that into the repo; 2. No, it is not «docs say», it is «sample script provided in docs does do that»
<gchristensen>
:P
<gchristensen>
I dunno, why not do any number of things which could make thinsgs better
<MichaelRaskin>
Well, to be honest I did not think to look into Wiki given that README seemed almost reasonable
<gchristensen>
aye
<MichaelRaskin>
Also, I wouldn't be able to use the script as is for two reasons…
<MichaelRaskin>
First is that you have just got the first succesful build from a non-NixOS x86_64-linux builder.
<gchristensen>
nice!
<MichaelRaskin>
I am not sure if it is globally the first, though.
<MichaelRaskin>
And it might not count because it runs Nixpkgs kernel.
<MichaelRaskin>
Not really nice, it means that I gave up on the HDD in the builder (which contained NixOS and locked up frequently), and I just put the same stuff as on the notebook
<MichaelRaskin>
(after buying a new HDD)
<MichaelRaskin>
Surprisingly enough, I didn't mess up too many things when deploying…
<MichaelRaskin>
(also, I now have no computers with NixOS installed)
<{^_^}>
[ofborg] @7c6f434c opened pull request #147 → Document my experience with re-setting-up a builder → https://git.io/vxR1G
<MichaelRaskin>
Ouch, I forgot to grant /dev/kvm to ofborg. Fixed, added to the PR…
orivej has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
Oops. I do sometimes launch multiple builders with same identity, and that also seems to work fine. Does this create non-obvious problems?
<MichaelRaskin>
(multiple builder instances on the same hardware)
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-borg
<MichaelRaskin>
Created separate configs/build directories for multiple builder instances. Is there a sane way to make them prefetch the repository before getting a command?
<MichaelRaskin>
Apparently violating the guidelines doesn't damage correctness (there is locking), but can lead to less efficient fetches.
<gchristensen>
The existing locking is not sufficiently safe and should be removed
<MichaelRaskin>
Or replaced with complete locking that would ensure that two builders cannot share a checkout at all?
<gchristensen>
That would be better
<MichaelRaskin>
Updated the PR to mention this in the README.md
<MichaelRaskin>
Hm. Do I understand correctly that GitHub hooks are configured to send to the RabbitMQ queue directly?
<gchristensen>
they send to _a_ rabbitmq queue directly
<MichaelRaskin>
Ah right, there are multiple.
<gchristensen>
they go to a queue to be filtered and then the filter triggers a job based on that
<MichaelRaskin>
Yes, that's what I assumed from ofborg code, but couldn't be sure where the GitHub hook points.
<gchristensen>
they're sent to the topical rabbitmq exchange github-events with the routing key "event-type.repoowner/reponame"
<gchristensen>
aye read these few lines of PHP and you're done
<MichaelRaskin>
I was thinking about what cheating tactics are there…
<gchristensen>
ah?
<gchristensen>
i know a few ...
<MichaelRaskin>
Well, you have eval check give a Details link
<MichaelRaskin>
Theoretically, it could be possible to create a link that goes via something access controlled (via GitHub team) to something that sends a job without requiring a GitHub comment
<gchristensen>
true!
<MichaelRaskin>
But it looks like it wouldn't be completely trivial starting from the current setup.
<gchristensen>
the hard thing is we have no ACL implementation beyond trusting github
<gchristensen>
so we'd need to create a github "app" and have people log in with github to use it
<MichaelRaskin>
Or post links for expected commands in a gist, include some validation keys, and access-control the gist
<gchristensen>
ooohh
<gchristensen>
well ...
<gchristensen>
no, because then we may as well disable the ACL
<MichaelRaskin>
The key is per-command, though.
<MichaelRaskin>
Including the revision.
<MichaelRaskin>
So if you share it, you delegate triggering the specific command, but not doing anything else in the future.