Commit graph

8 commits

Author SHA1 Message Date
Graham Christensen e4cda87b5a
db.hh: use hasPrefix for prefix comparisons
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
2021-02-24 07:00:26 -05:00
Graham Christensen fe1f2f0806
Create an ephemeral PostgreSQL database per test 2021-02-23 21:12:06 -05:00
Eelco Dolstra 7985757a1d
Fix build 2020-07-08 12:50:02 +02:00
Eelco Dolstra e4f5156c41
Build against nix-master
(cherry picked from commit e7f2139e25)
2020-02-20 10:24:04 +01:00
Hamish Mackenzie c40c887e50
Fixes for macOS
Building on macOS with the latest nixpkgs master and NixOS/nixpkgs#77147
fails.  It seems some `std::experimental` (optional) for instance are
not available as `experimental`, but are in `std`.  Also `toJSON` is
missing for `atomic< unsigned long long >`.
2020-01-07 12:38:06 +13:00
Eelco Dolstra 4e27796eba
Allow setting GC_INITIAL_HEAP_SIZE for hydra-eval-jobs
This cannot be done in the hydra-evaluator systemd unit, since then
every other Nix process (e.g. hydra-evaluator and nix-prefetch-*) will
also allocate the specified heap size, probably leading to OOM.
2018-05-16 14:14:53 +02:00
Eelco Dolstra dc5e0b120a
Fix a race that can cause hydra-queue-runner to ignore newly added builds
As @dtzWill discovered, with the concurrent hydra-evaluator, there can
be multiple active transactions adding builds to the database. As a
result, builds can become visible in a non-monotonically increasing
order, breaking the queue monitor's assumption that build IDs only go
up.

The fix is to have hydra-eval-jobset provide the lowest build ID it
just added in the builds_added notification, and have the queue
monitor check from there.

Fixes #496.
2017-07-21 14:34:48 +02:00
Eelco Dolstra e0b2921ff2 Concurrent hydra-evaluator
This rewrites the top-level loop of hydra-evaluator in C++. The Perl
stuff is moved into hydra-eval-jobset. (Rewriting the entire evaluator
would be nice but is a bit too much work.) The new version has some
advantages:

* It can run multiple jobset evaluations in parallel.

* It uses PostgreSQL notifications so it doesn't have to poll the
  database. So if a jobset is triggered via the web interface or from
  a GitHub / Bitbucket webhook, evaluation of the jobset will start
  almost instantaneously (assuming the evaluator is not at its
  concurrency limit).

* It imposes a timeout on evaluations. So if e.g. hydra-eval-jobset
  hangs connecting to a Mercurial server, it will eventually be
  killed.
2016-10-14 14:22:12 +02:00