GithubHelp home page GithubHelp logo

nixos / ofborg Goto Github PK

View Code? Open in Web Editor NEW
229.0 33.0 163.0 2.26 MB

@ofborg tooling automation https://monitoring.ofborg.org/dashboard/db/ofborg

Home Page: https://ofborg.org

License: MIT License

PHP 1.67% Nix 19.83% Rust 78.10% Shell 0.40%

ofborg's Introduction

ofborg

Guidelines

  1. Review the code of all PRs before triggering the bot on them.
  2. Be gentle; try not to run mass rebuilds or massive builds (like Chromium) on it.

Automatic Building

All users will have their PRs automatically trigger builds if their commits follow the well-defined format of Nixpkgs. Specifically: prefixing the commit title with the package attribute. This includes package bumps as well as other changes.

Example commit titles and the builds they will start:

Message Automatic Build
vim: 1.0.0 -> 2.0.0 vim
vagrant: Fix dependencies for version 2.0.2 vagrant
python36Packages.requests,python27Packages.requests: 1.0.0 -> 2.0.0 python36Packages.requests, python27Packages.requests
python{27,310}Packages.requests: 1.0.0 -> 2.0.0 python27Packages.requests, python310Packages.requests

When opening a PR with multiple commits, ofborg creates a single build job for all detected packages. If multiple commits get pushed to a PR one-by-one, each detected package will get a separate build job.

If the title of a PR begins with WIP:, contains [WIP] anywhere, or has the 2.status: work-in-progress label, its packages are not built automatically. Note: Marking a PR as a draft does not prevent automatic builds.

Commands

The comment parser is line-based, so commentary can be interwoven with instructions for ofborg.

  1. To trigger the bot, the line must start with @ofborg (case insensitive).
    • Note: GitHub will not suggest @ofborg to you, but it will work all the same. When in doubt, preview your comment and verify that @ofborg links to https://github.com/ofborg/.
  2. To use multiple commands, separate them with whitespace. For examples, see the "Multiple Commands" section.

test

@ofborg test list of tests

This will run nix-build ./default.nix -A nixosTests.list -A nixosTests.of -A nixosTests.tests from the root of the Nixpkgs checkout.

Tests will run on all allowed machines. For more information, see the "Trusted Users" section.

eval

@ofborg eval

See "How does ofborg call nix-instantiate?" for what command(s) this will run.

Note: Every PR automatically evaluates both upon creation and when the commits change. There is no reason to run eval on a PR unless the evaluation failed for weird reasons or master was previously broken.

build

@ofborg build list of attrs

This will run nix-build ./default.nix -A list -A of -A attrs from the root of the Nixpkgs checkout (see also "How does ofborg call nix-build?").

Builds will run on all allowed machines. For more information, see the "Trusted Users" section.

Multiple Commands

You can use multiple commands in a variety ways. Here are some valid combinations:

  • @ofborg build list of attrs
    @ofborg eval
    
  • @ofborg build list of attrs @ofborg eval
    
  • looks good to me!
    @ofborg eval
    @ofborg build list of attrs
    
  • @ofborg eval
    @ofborg build list of attrs
    looks good to me!
    
  • @ofborg build list of attrs
    @ofborg test list of attrs
    
  • This will build list, of, attrs, looks, good, to, and me! (which is probably not what you want):

    @ofborg build list of attrs looks good to me!
    

Trusted Users (Currently Disabled)

NOTE: The Trusted Users functionality is currently disabled, as the current darwin builder is reset very frequently. This means that all users will have their PRs build on the darwin machine.

Trusted users have their builds and tests executed on all available platforms, including those without good sandboxing. Because this exposes the host to a higher risk of security issues, the trusted users list consists of only well-known, trusted members of the community.

At the time of writing, trusted users have their builds and tests run on these platforms:

  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

See config.public.json for a list of all trusted users.

How does ofborg call nix-build?

ofborg runs builds with a command similar to the following:

$ HOME=/homeless-shelter NIX_PATH=ofborg-nixpkgs-pr=$(pwd) nix-build ./default.nix \
    -A hello \
    --no-out-link \
    --keep-going \
    --option restrict-eval true \ 
    --option build-timeout 1800 \ 
    --argstr system thesystem \
    --show-trace

How does ofborg call nix-instantiate?

ofborg runs NixOS evals with a command similar to the following:

$ HOME=/homeless-shelter NIX_PATH=ofborg-nixpkgs-pr=$(pwd) nix-instantiate ./nixos/release.nix \
    -A manual \
    --option restrict-eval true \
    --option build-timeout 1800 \
    --argstr system thesystem \
    --show-trace

ofborg runs Nixpkgs evals with a command similar to the following:

$ HOME=/homeless-shelter NIX_PATH=ofborg-nixpkgs-pr=$(pwd) nix-instantiate ./pkgs/top-level/release.nix \
    -A manual \
    --option restrict-eval true \
    --option build-timeout 1800 \
    --argstr system thesystem \
    --show-trace

Running meta checks locally

To run the meta checks, you will need the outpaths.nix file. You can acquire this file and run the checks themselves like so:

$ curl -o outpaths.nix https://raw.githubusercontent.com/NixOS/ofborg/released/ofborg/src/outpaths.nix
$ GC_INITIAL_HEAP_SIZE=4g nix-env -f ./outpaths.nix -qaP --no-name --out-path --arg checkMeta true > out-paths

Hacking

$ git clone https://github.com/NixOS/ofborg/
$ cd ofborg
$ nix-shell ./shell.nix
$ cd ofborg # enter the subdirectory with Rust code
# make your changes
$ cargo build
$ cargo check
$ cargo test

To test whether or not Continuous Integration will pass with your changes, you can run the following commands from the root of your checkout:

$ nix-shell --pure --run checkPhase # checks rustfmt, clippy & runs the test suite
$ nix-build -A ofborg.rs # build ofborg

Currently there is no easy way to set up a test instance of ofborg. If cargo check and cargo test both succeed, feel free to Pull Request your changes. Make sure to format your code with cargo fmt and check for additional warnings with cargo clippy.

To disable warnings as errors, run your command with an empty RUSTFLAGS. For example:

$ RUSTFLAGS= cargo clippy

This will override the default of -D warnings set in shell.nix, which tells Rust to error if it detects any warnings.

Running a builder

If you want to run a builder of your own, check out the wiki page on operating a builder.

ofborg's People

Contributors

aanderse avatar adisbladis avatar alyssais avatar andir avatar artturin avatar cole-h avatar edef1c avatar ekleog avatar fgaz avatar flokli avatar fridh avatar grahamc avatar infinisil avatar lilyinstarlight avatar lnl7 avatar makefu avatar mic92 avatar mmahut avatar rnhmjoj avatar ryantm avatar samueldr avatar supersandro2000 avatar synthetica9 avatar teto avatar tilpner avatar worldofpeace avatar xeji avatar xrelkd avatar zimbatm avatar zowoq avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ofborg's Issues

Ping meta.maintainers

We still need to ping maintainers of packages/modules in case their expressions are modified.

Proposal:

  1. use nix-env to check which packages need to be rebuild
  2. retrieve for each package meta.position
  3. check if the file specified in 2) is in the diff. If so, ping the maintainers listed in somepkg.meta.maintainers.

The attributes are typically GitHub handles, but as far as I know there is no way in Nix to get that handle.

Two possible solutions to retrieve the handle:

  1. rewrite lib.maintainers (NixOS/nixpkgs#18352 (comment))
  2. use sed

Add tags based on files that are touched.

If certain Python-related files are touched I would like to have a python tag.

I don't think we could use the codeowners file, but we may use a similar file. Basically, a list of regexes and a tag.

Feature Request: Automatic merging

It's a security concern to have so many contributors to Nixpkgs with write access. Eventually, I think we will want to start removing commit access for inactive contributors.

For now, though, there's not a very easy way to contribute to Nixpkgs without having write access. I'm thinking "Ofborg" might be able to help with that. A basic proposal (maybe needs to be an RFC):

When at least 1 "known user" approves a PR based on master and all tests have passed, a timer is set for 24 hours. Ofborg sends a comment explaining the 24 hour rule and the expected merge time. After 24 hours, Ofborg checks that: no changes have been requested, no commits have been changed, and that the PR is mergeable into master. If all checks pass, Ofborg automatically merges the PR into master.

The idea is not to replace regular merging but to provide an alternative route for "harmless PRs". Once feedback is given, then it's assumed that manual merging should take place (veto). "Harmless PRs" would include things like new packages and package updates. Users with commit access can still revert the merge later on if they object. The goal is to cut down on the number of open PRs and also make life easier for some of the "mergers".

See also NixOS/nixpkgs#20836

builder stops receiving builds after running for a while

This is probably some sort of connection issue, I'll add the debug log when I this happens again.

...
DEBUG:amq_proto::protocol::basic: Decoding basic.deliver
DEBUG:amqp::channel: Sending method basic.publish to channel 1
DEBUG:amqp::channel: Sending method basic.ack to channel 1
DEBUG:amq_proto::protocol::basic: Decoding basic.deliver
DEBUG:amqp::channel: Sending method basic.publish to channel 1
DEBUG:amqp::channel: Sending method basic.ack to channel 1

visual presentation of builds

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.

[Feature requests] nixos tests

if there are no tests for a given package, I have to build the package myself anyway to test functionality.
A green nixos test is more actionable.

GitHub Comment Coalescing

Ofborg is growing a nice feature set, and with it more things to say on every issue. With two-to-three comments per issue, I think we're at risk of sending too much noise.

One solution is to coalesce replies in to a single comment. This would ideally be one comment per call, not one comment per issue. In other words, if there are two calls on the issue:

image

this would result in two comments, one per call.

what I'd do once we have this

  • Update the issue to say the commands were received and where they will run
  • Update the issue when a build starts running (already can be known via the logs exchange)
  • Provide a link to the log viewer

down sides

  • GitHub doesn't properly propagate comment updates sometimes when the page is already loaded, so maybe people will feel they aren't getting feedback because they don't see anything changing
  • GitHub's comments isn't a transactional database and so if there are multiple poster jobs running simultaneously, comments could be easily lost. Additionally, updates could easily be lost if there is replication lag or cache problems on GitHub.

implementation details

  • when a job is scheduled in the githubcommentfilter job, we should generate a call_id and pass that to the build job
  • the builder should include call_id in the BuildLogStart message
  • when a build is finished, the builder should include the call_id in the BuildResult message
  • the poster job should be rewritten in Rust first
  • the poster job should include the call ID in each comment it leaves
  • the poster job should look for an existing comment with the call ID and append its message to the end

[Feature request] Select platform

I propose that it should either be possible to select a target platform or (minimally) Borg should not report errors for platforms that are specifically not supported (like a Linux kernel on Darwin :D)

Distinguish tests from evals and other checks more closely

When I run the test command, currently I get a comment response like:

Failure on aarch64-linux (full log)

Partial log (click to expand)

which is the same like a normal build response, and I can see whether it was for the test or the build only by looking at the log.
This is especially confusing when giving multiple commands, like I did in in NixOS/nixpkgs#35194 (comment)

I propose changing the comment text to contain a reference to what was built/evaluated/tested, like

Test for `rabbitmq` failed on `aarch64-linux` (full log)

Partial log:

Be able to run oborg's meta checks on a local branch

Be able to do like:

$ cd nixpkgs
$ ofborg eval-checks

grahamcofborg-eval-nixos-manual — LGTM
grahamcofborg-eval-nixos-options — LGTM
grahamcofborg-eval-nixpkgs-manual — LGTM
grahamcofborg-eval-nixpkgs-tarball — LGTM
grahamcofborg-eval-nixpkgs-unstable-jobset — LGTM
grahamcofborg-eval-package-list — LGTM

Would label: 10.rebuild-linux:1-10
Would label: 10.rebuild-darwin:0

Automatic Merging Implementation

I would add the following command:

@GrahamCOfBorg build-and-merge foo bar baz

Then, if:

  • You are unknown: the command is ignored
  • You are a known or trusted user: the builds are queued
  • You are a Nixpkgs member (a subset of the known users): a merge job
    is queued

If a merge job is queued, it will contain:

  • a "command ID". All build jobs from this command will carry the same
    command ID.
  • a list of build jobs triggered to wait for

The merge job will then wait for each build job to complete.

If any return a Failure, the merge job is canceled.

If the PR's status checks fail, the job is canceled.

If any known or trusted user comments:

@GrahamCOfBorg cancel

after the command was issued, the job is canceled.

When all of the jobs complete with Success or "not attempted" (a special
status to indicate the job wasn't possible, like building systemd on
x86_64-darwin) the PR is then merged by OfBorg's user. The merge
commit will indicate who issued the merge command.

Evaluation errors

It would be nice if evaluation issues could print a few more lines of info

See NixOS/nixpkgs#31737

error: Package ‘docker-17.09.0-ce’ in /var/lib/gc-of-borg/.nix-test/mr-est-38dca4e3aa6bca43ea96d2fcc04e8229-31737/pkgs/applications/virtualization/docker/default.nix:190 is not supported on ‘x86_64-linux’, refusing to evaluate.

RabbitMQ Stability

I really don't like to restart RabbitMQ because not all clients properly handle the disconnect. However, it must be done, especially under NixOS where it restarts practically every time the channel updates.

  • write a nix-darwin service for a builder, ensuring it has some restart logic
  • convert graham's mac to use nix-darwin
  • configure RabbitMQ to listen on ipv6 since the DNS record already has an AAAA.
  • ensure the core services don't restart too fast and will continue trying to start for several minutes
  • ensure the rust workers properly detect a lost connection
  • implement better heartbeats
  • in the PHP code receiving events from GitHub, it should repeatedly attempt to connect to RabbitMQ and send the event, for up to 30 seconds, to better handle events sent during a transient problem

In the future we may want multiple rabbitmq nodes, but clustering can be annoying, so I'm punting on that for now.

Feature Request: Warn when mass rebuild PR has wrong base

This is a small feature request I have that would be helpful for PRs.

Basically, when either 'rebuild-darwin: 501+' or 'rebuild-linux: 501+' is found, check what the base branch is. If it's based off of 'master', post a warning message from @GrahamcOfBorg explaining that it should be based off of 'staging' instead (except in rare circumstances).

Build a lot more stuff

We've got a good bit of build capacity and it goes largely unused:

builds

Worse, x86_64-linux has effectively unbounded capacity due to a generous spot instance backing. Darwin is the least strong, and aarch64-linux is in the middle.

For these reasons, I'd like to build way more PRs and use this capacity to make merging PRs easier and safe.

Phase One: Simple Expansion

  • Setup sandboxing properly on all the macs
  • Backport the sandboxing code from master to 17.09
  • Expand caller access to everyone with merge writes on nixos/nixpkgs

Phase Two: Easier Build Selection

  • Implement build "sampling" where ofborg automatically selects a handful of attrs to build based on what has changed in the PR.
  • Implement test sampling where ofborg does the same thing, but selects a handful of changed tests.

Phase Three: Limited Automatic Building

  • Sucker Convince someone to buy me / provide me with a bunch of macs to enroll for capacity
  • Automatically sample PRs from anyone trusted to call ofborg

Phase Four: Automatic Building

  • Automatically sample all PRs

Automatically tag issues with data from nix-info

What tags would be helpful and can get extracted from the issue?

Example

  • system: "x86_64-darwin"
  • host os: Darwin 14.5.0, macOS 10.10.5
  • multi-user?: yes
  • sandbox: no
  • version: nix-env (Nix) 1.11.13
  • channels(davidak): "nixpkgs-18.03pre121255.45a85eaceb"
  • channels(root): "nixpkgs-18.03pre121255.45a85eaceb"
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixpkgs

So we get the information that the user has the issue with this system. That does not mean that it appears only on this kind of system. Often other users mention in the comments that they also have the same problem on a different system. But then, additional tags can be added manually.

We could extract:

  • 6.topic: darwin
  • OS version like 17.09 on NixOS (?)
  • Nix version (?)
  • maybe we can enhance nix-info to output if the channel is stable, small or unstable?

Since i'm not involved in tagging, let's ask people that are.

cc @joachifm @vcunat @NeQuissimus @FRidh

Build failure: all build users are currently in use

Failure on aarch64-linux (full log)

Partial log (click to expand)

building '/nix/store/lm0s1yhqslr1yf2n892qkwpld3r3ykia-unit-systemd-journal-flush.service.drv'...
building '/nix/store/hf1qr9bqillcz54wwr58fiy75d4mbga1-unit-systemd-journald.service.drv'...
building '/nix/store/g54j9nmdzcqdaz0jn1x1cbiflz5jvkvv-unit-systemd-logind.service.drv'...
building '/nix/store/fsvhkwx4xv9d0c3fpwy7sjqxiyqmxl04-unit-systemd-modules-load.service.drv'...
building '/nix/store/r858h9vsgbzyfgrcw6gx7syxc8iikpga-unit-systemd-random-seed.service.drv'...
building '/nix/store/cs4k3mggbq661qhlv44c16f9xsx8l1jn-unit-systemd-remount-fs.service.drv'...
building '/nix/store/2cyv967hcb8iywbqabn9c0cbghfq5vyl-unit-systemd-timedated.service.drv'...
building '/nix/store/jksb7zx5p7m3h37yqpml1zi5aib2hry3-unit-systemd-update-utmp.service.drv'...
building '/nix/store/07yvcq5x9r8sbzkx6c398w79fcqb30yz-unit-systemd-user-sessions.service.drv'...
�[31;1merror:�[0m all build users are currently in use; consider creating additional users and adding them to the 'nixbld' group

Provide a binary cache for builds

It would be pretty cool, if the builds of ofborg would also be downloadable.
Then maintainers could get quite a lot more pull requests tested in shorter time.

If there would be a url where a expression with expression tarball could be downloaded,
then one could do something like (it should be also possible to provide an actual tarball url for github pull requests)

$ nix-shell 'https://gist.github.com/Mic92/93f65c4d42ac72c8d64397258cada90c/archive/0159f2d6894ea2928e0b05d6ee46349be81681d6.tar.gz' --command 'studio-link'

Bot that posts pre-defined comments and checklists based on files that are touched or other rules

It would be nice if a bot would post pre-defined comments and/or checklists based one or more rules that are fulfilled. Types of rules could be

  • file is touched
  • regex matches on contents
  • regex matches on commit name
  • ...

The output is markdown.

The rules could be defined in a yaml or json file, however, if we want to match on multiple rules it may be useful to define them instead in Nix.

Example rules in some pseudo-code form:

if file in ["pkgs/development/python-modules/*" "pkgs/top-level/python-packages.nix" ] then post ''
- By default we enable tests. Make sure the tests are found and, in the case of libraries, are passing for all interpreters. If certain tests fail they can be disabled individually. Try to avoid disabling the tests altogether. In any case, when you disable tests, leave a comment explaining why.    
''

Check of commands in the initial PR message

It would be nice to be able to issue commands immediately in the PR message rather than starting a "discussion" (thus adding that nasty icon that may lead people to believe a PR is already being handled :-)

Tags: support `8.has: package (new)`

The 8.has: package (new) tag is perhaps one of the most uninteresting tags we have because packages are added continuously. At the same time, for statistical purposes this tag may be interesting.

We could assign this tag based on whether a PR has a net increase in amount of packages as listed by nix-env -qaP. This makes the assumption that we count a new version of a package also as a new package. I don't mind that, actually.

At the same time, when there is a net decrease in amount of packages, we may also add the 8.has: clean-up tag.

Failed evaluation

Evaluation fails on NixOS/nixpkgs#31683 for unknown reason, quoting @grahamc:

Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(57) "Estimating rebuild amount by counting changed Hydra jobs."
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [1]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(155) "error: while evaluating anonymous function at /tmp/nix-rebuild-amount-YfwaDe6R:13:12, called from /tmp/nix-rebuild-amount-ZGmw0xJG/lib/attrsets.nix:199:52:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [2]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(111) "while evaluating the attribute ‘x86_64-darwin’ at /tmp/nix-rebuild-amount-ZGmw0xJG/lib/attrsets.nix:185:41:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [3]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(178) "while evaluating anonymous function at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/top-level/release-lib.nix:66:6, called from /tmp/nix-rebuild-amount-ZGmw0xJG/lib/attrsets.nix:282:43:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [4]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(180) "while evaluating ‘hydraJob’ at /tmp/nix-rebuild-amount-ZGmw0xJG/lib/customisation.nix:157:14, called from /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/top-level/release-lib.nix:66:14:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [5]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(110) "while evaluating the attribute ‘drvPath’ at /tmp/nix-rebuild-amount-ZGmw0xJG/lib/customisation.nix:174:13:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [6]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(110) "while evaluating the attribute ‘drvPath’ at /tmp/nix-rebuild-amount-ZGmw0xJG/lib/customisation.nix:145:40:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [7]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(166) "while evaluating the attribute ‘cc’ of the derivation ‘clang-wrapper-3.4.2’ at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [8]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(167) "while evaluating the attribute ‘postInstall’ of the derivation ‘clang-3.4.2’ at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [9]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(165) "while evaluating the attribute ‘cmakeFlags’ of the derivation ‘llvm-3.4.2’ at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [10]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(135) "while evaluating the derivation attribute ‘name’ at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [11]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(119) "attribute ‘version’ missing, at /tmp/nix-rebuild-amount-ZGmw0xJG/pkgs/development/libraries/libbfd/default.nix:6:26"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [12]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(155) "error: while evaluating anonymous function at /tmp/nix-rebuild-amount-MyLlifBZ:13:12, called from /tmp/nix-rebuild-amount-EXW3wJHS/lib/attrsets.nix:199:52:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [13]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(111) "while evaluating the attribute ‘x86_64-darwin’ at /tmp/nix-rebuild-amount-EXW3wJHS/lib/attrsets.nix:185:41:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [14]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(178) "while evaluating anonymous function at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/top-level/release-lib.nix:66:6, called from /tmp/nix-rebuild-amount-EXW3wJHS/lib/attrsets.nix:282:43:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [15]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(180) "while evaluating ‘hydraJob’ at /tmp/nix-rebuild-amount-EXW3wJHS/lib/customisation.nix:157:14, called from /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/top-level/release-lib.nix:66:14:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [16]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(110) "while evaluating the attribute ‘drvPath’ at /tmp/nix-rebuild-amount-EXW3wJHS/lib/customisation.nix:174:13:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [17]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(110) "while evaluating the attribute ‘drvPath’ at /tmp/nix-rebuild-amount-EXW3wJHS/lib/customisation.nix:145:40:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [18]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(166) "while evaluating the attribute ‘cc’ of the derivation ‘clang-wrapper-3.4.2’ at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [19]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(167) "while evaluating the attribute ‘postInstall’ of the derivation ‘clang-3.4.2’ at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [20]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(165) "while evaluating the attribute ‘cmakeFlags’ of the derivation ‘llvm-3.4.2’ at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [21]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(135) "while evaluating the derivation attribute ‘name’ at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/stdenv/generic/make-derivation.nix:98:11:"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   [22]=>
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]:   string(119) "attribute ‘version’ missing, at /tmp/nix-rebuild-amount-EXW3wJHS/pkgs/development/libraries/libbfd/default.nix:6:26"
Nov 15 14:30:17 zoidberg grahamcofborg-mass-rebuilder-start[29678]: }

I'll have to look in to why the eval check thinks this is OK, but the estimator thinks it isn't. Also, I need to fix the estimator to exit non-zero on eval errors :)

Error messages

As mentioned in #112:

When a user oversteps his privileges (issuing build and/or merge commands without being trusted/Nixpkgs member for example), it woudl be nice if ofBorg would give feedback.

Similarly when a user specifies a not-known command (typos).

Capture Nix stats during eval

It would be great to track the Nix evaluation stats over time. An example of these stats are as follows:

grahamc@Morbo> export NIX_SHOW_STATS=1 NIX_COUNT_CALLS=0; cp ../ofborg/ofborg/src/outpaths.nix .; nix-env -f ./outpaths.nix -qaP --no-name --out-path --arg checkMeta true > outs
evaluation statistics:
  time elapsed: 113.927
  size of a value: 24
  size of an attr: 24
  environments allocated: 51021608 (1605585144 bytes)
  list elements: 84838642 (678709136 bytes)
  list concatenations: 5012224
  values allocated: 144000479 (3456011496 bytes)
  sets allocated: 14772174 (4559741232 bytes)
  right-biased unions: 7603556
  values copied in right-biased unions: 130009211
  symbols in symbol table: 288036
  size of symbol table: 11669838
  number of thunks: 97110210
  number of thunks avoided: 85959307
  number of attr lookups: 44963046
  number of primop calls: 35071263
  number of function calls: 45204301
  total allocations: 10300047008 bytes
  current Boehm heap size: 8598323200 bytes
  total Boehm heap allocations: 13792084256 bytes

However, to avoid some ad-hoc parsing of this data, it would be nice if this information could be written out to a separate file, perhaps provided by an environment variable, like NIX_WRITE_STATS=/tmp/nix-eval-stats.

Additionally, it would be cool if it was a bit more simple:

  time elapsed: 113.927
  size of a value: 24
  size of an attr: 24
  environments allocated count: 51021608
  environments allocated bytes: 1605585144
  list elements count: 84838642
  list elements bytes: 678709136
  list concatenations: 5012224
  values allocated count: 144000479
  values allocated bytes: 3456011496
  sets allocated count: 14772174
  sets allocated bytes: 4559741232
  right-biased unions: 7603556
  values copied in right-biased unions: 130009211
  symbols in symbol table: 288036
  size of symbol table: 11669838
  number of thunks: 97110210
  number of thunks avoided: 85959307
  number of attr lookups: 44963046
  number of primop calls: 35071263
  number of function calls: 45204301
  total allocations: 10300047008 bytes
  current Boehm heap size bytes: 8598323200
  total Boehm heap allocations bytes: 13792084256

The code is here: https://github.com/NixOS/nix/blob/master/src/libexpr/eval.cc#L1700

consistent fwupd build test failure on test command

When I issue @GrahamcOfBorg build fwupd, the checkPhase is consistently succeeding (https://logs.nix.ci/?key=nixos/nixpkgs.35065&attempt_id=b609fea1-6c5c-4e37-884c-0321d2e216c4) but for @GrahamcOfBorg test fwupd, thunderbolt-self-test fails every time (https://logs.nix.ci/?key=nixos/nixpkgs.35065&attempt_id=82c43b46-d995-48df-b7aa-77ba8491d664):

 9/11 thunderbolt-self-test                   FAIL     0.02 s
--- command ---
LD_PRELOAD='/nix/store/085rz1chj77nsw9zi08p13vx8lq87prv-umockdev-0.11/lib/libumockdev-preload.so.0' /build/fwupd-1.0.5/build/plugins/thunderbolt/thunderbolt-self-test
--- stdout ---
/thunderbolt/basic:
--- stderr ---
(/build/fwupd-1.0.5/build/plugins/thunderbolt/thunderbolt-self-test:16712): FuPluginThunderbolt-WARNING **: Need to run within umockdev wrapper (umockdev-wrapper thunderbolt-self-test)!

I have tried checking out master, merging the fwupd branch and running env HOME=/homeless-shelter NIX_PATH=nixpkgs=$(pwd) nix-build ./nixos/release.nix --no-out-link --keep-going -A tests.fwupd.x86_64-linux --option restrict-eval true --option build-timeout 1800 --argstr system x86_64-linux --show-trace locally but it succeeded.

Edit: We have since observed the issue even in build command, so the problem is not actually caused by the test environment being different. Most likely it is a problem with a specific machine?

Access Request

If you'd like access, please open a PR like this: #71

Please leave a comment if you would like access

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.