grahamcofborg

Guidelines

1. make sure you've reviewed the code before you trigger it on a PR that isn't your own
2. be gentle, preferably don't run mass rebuilds / massive builds like chromium on it

Commands

1. To trigger the bot, the comment must start with a case insensitive version of @GrahamcOfBorg.
2. To use multiple commands, insert a bit of whitespace and then your new command.

Commands:

test (added: 2017-11-24)

@grahamcofborg test list of tests

This will run nix-build ./nixos/release.nix -A tests.list -A tests.of -A tests.attrs in the nixpkgs checkout. Note: this will only run on x86_64-linux machines.

eval

@grahamcofborg eval

Note: Every PR automatically evaluates when it is opened and when the commits change. There is no reason to run eval on a PR unless the evaluation has failed for weird reasons, or because master was broken before.

build

@grahamcofborg build list of attrs

This will run nix-build ./default.nix -A list -A of -A attrs in the nixpkgs checkout.

---

Multiple Commands:

@grahamcofborg build list of attrs
@grahamcofborg eval

or even:

@grahamcofborg build list of attrs @grahamcofborg eval

This will not work:

looks good to me!
@grahamcofborg build list of attrs

Also this is bad:

@grahamcofborg build list of attrs
looks good to me!

as it'll try to build list of attrs looks good to me!.

arch

1. All github events go in to web/index.php, which sends the event to an exchange named for the full name of the repo (ex: nixos/nixpkgs) in lower case. The exchange is set to "fanout"
2. build-filter.php creates a queue called build-inputs and binds it to the nixos/nixpkgs exchange. It also creates an exchange, build-jobs, set to fan out. It listens for messages on the build-inputs queue. Issue comments from authorized users on PRs get tokenized and turned in to build instructions. These jobs are then written to the build-jobs exchange.
3. builder.php creates a queue called build-inputs-x86_64-linux, and binds it to the build-jobs exchange. It then listens for build instructions on the build-inputs-x86_64-linux queue. For each job, it uses nix-build to run the build instructions. The status result (pass/fail) and the last ten lines of output are then placed in to the build-results queue.
4. poster.php declares the build-results queue, and listens for messages on it. It posts the build status and text output on the PR the build is from.

Getting Started

• you'll need to create the WORKING_DIR
• nix-shell
• composer install
• php builder.php

The conspicuously missing config.php looks like:

<?php

require_once __DIR__ . '/vendor/autoload.php';
use PhpAmqpLib\Connection\AMQPSSLConnection;
use PhpAmqpLib\Message\AMQPMessage;

define("NIX_SYSTEM", "x86_64-linux");
define("WORKING_DIR", "/home/grahamc/.nix-test");

function rabbitmq_conn() {
    $connection = new AMQPSSLConnection(
        'events.nix.gsc.io', 5671,
        eventsuser, eventspasswordd, '/', array(
            'verify_peer' => true,
            'verify_peer_name' => true,
            'peer_name' => 'events.nix.gsc.io',
            'verify_depth' => 10,
            'ca_file' => '/etc/ssl/certs/ca-certificates.crt'
        )
    );

    return $connection;
}

/*
# Only leader machines (ie: graham's) need this:
function gh_client() {
    $client = new \Github\Client();
    $client->authenticate('githubusername',
                          'githubpassword',
                          Github\Client::AUTH_HTTP_PASSWORD);

    return $client;
}
*/

Getting started on the rust one...

nix-shell ./shell.nix -A rustEnv
$ cd ofborg
$ cargo build

cargo build

then copy config.example.json to config.json and edit its vars. Set nix.remote to an empty string if you're not using the daemon.

Run

./target/debug/builder ./config.json