We emit a few jobs conditionally on supportDarwin which only checked for
x86_64-darwin in the past. This change makes it more modular by
transforming it into an attribute set which holds the two darwin
arches. Jobs needing aarch64-darwin or x86_64-darwin are now only
emitted if their respective platform is actually in supportedSystems.
This issue was discovered because the staging-next-21.11 jobset had
commented out x86_64-darwin (presumably due to a build load issue).
Having pkgsLLVM.stdenv built with nixpkgs:trunk will make building
anything in pkgsLLVM decidedly less painful since it will eliminate
the need to build LLVM and clang locally, which shouldn't be as bad
on hydra.
Darwin is disabled for now since it doesn't evaluate correctly there
(infinite recursion problem with the SDK).
This reverts commit c23e9e12f8.
At this moment the benchmarking machine ("t2a") is unreachable from
outside due to IPv6 issues. (the "t4a" and "t4b" builders as well)
But even generally I can't see why this job should block channels,
provided that it won't remain broken over long term.
* Add pkgsMusl.stdenv to block nixpkgs channel
* Don’t include i686-linux for pkgs{Musl,Static}
musl bootstrapping is unavailable for i686-linux right now. so we can
just exclude it from hydra.
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
This reverts commit 5e8545e723.
It breaks eval:
attribute 'rev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-0-gleber.ewr1.nix.ci/pkgs/top-level/make-tarball.nix:106:39
This package is hardly used in Nixpkgs. Why is it considered
sufficiently important to block a channel?
It's been blocking the nixpkgs-unstable for 8 days now, so removing it
from release*.nix.
The comment in this file about why nox is here
was "Needed by travis-ci to test PRs", and we
for sure don't use travis-ci anymore.
Instead we're making nixpkgs-review a deliverable
because it's included in the PR template as a tool
to use. We also swapped out nox for nixpkgs-review
in the PR template, so I believe this makes sense
here because it was changed.
This reverts commit 96d73edaf3.
IPv6 connectivity restored by ISP a few hours after I pushed
the workaround. Apparently it was something complicated;
I suppose that has to do with the issue appearing on Friday 13th
during full moon ;-)
Since friday the metrics machine (along with other replaceable ones)
has no public-IP connectivity. I hoped I'd be able to resolve this
with ISP quickly, but apparently not. Let's not block the channel
at least. The metrics data can get filled retrospectively by restarting
the individual Hydra jobs.
Unfortunately it is broken and I won’t have time to fix right now.
Most likely we will have to wait until the macOS 10.12 update to get
this one working again.
(cherry picked from commit 70f1335f8d64d1f8451b891d4fca4af08e607d09)
Hydra passes the full revision in to the input, which we pass through.
If we don't get this ,we try to get it from other sources, or default to
master which should have the definition in a close-ish location.
All published docs should have theURL resolve properly, only local
hackers will have the link break.
