This is a new flag introduced in `nix-eval-jobs`, which reduces runtime
for the `ping-maintainers` subcommand from 12 minutes to 3 minutes for
me.
The `--constituents` flag is not supported anymore with
`--no-instantiate`, but it doesn't seem to make a difference anyway.
Same for `--max-jobs` - I don't get a difference with or without it.
Removing the `foldl'` import because it is warned to be redundant after
switching to import the current nixpkgs instance, likely due to a newer
GHC version (?).
Hydra unilaterally removed hydra-eval-jobs, so we need to figure out how
to migrate to nix-eval-jobs. I can't shake the feeling that it's slower.
Maybe we need to increase the resource limitations for nix-eval-jobs.
nix-eval-jobs no longer produces a big JSON object, but instead one
object per line (one for each job). This is supported in a simple way by
readJSONLinesProcess. It'd be possible to implement this without
presupposing that there's one object per line, however, it is not an
usecase exactly intended by aeson, it seems.
nix-eval-jobs makes our job easier in some ways, e.g. jobs have a proper
meta set now, so we no longer need to cross reference a mail address to
github handle map. There is even room for further improvement, e.g.
attribute paths can just be queried instead of generating them using
Text.splitOn.
See also https://github.com/NixOS/hydra/pull/1421.
In practice, almost all requests to Hydra take longer than the default
timeout of 30 seconds.
This commit bumps all requests to the max timeout of 15 minutes. This
should hopefully make the hdyra-report.hs script more reliable and fail
less.
This change adds a flag --slow to hydra-report.sh get-report which
causes it to fetch the cheap evaluation overview endpoint (which only
contains build ids and meta data). The gathered information is then used
to request each build's status individually instead of in bulk which is
very slow, but useful as a last resort if the bulk endpoint times out.
Since every failure in the jobset means one request to get the log when
generating the list of newly broken packages, we need to add an option
to disable log requesting in case a lot of new breakage needs to be
entered.
Add a newtype for a package name and a package set. This is less for
correctness, and more just to make the code a little easier to read
through without having to keep in mind what each Text refers to.
nixpkgs:trunk also builds aarch64-darwin these days, so this forces our
hand a little bit. We can still refuse to care about failures _too_
much, but at least we will stop merging as big a rebuilds as we are
currently.
