I'm deploying my own Hydra via flakes for a while now and while this
package actually needs more love and a few updates, I don't have the
capacity to take care of this.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c3490196).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
This plugin allows configuring the URLs generated by Catalyst (and
therefore by Hydra) to be relative instead of absolute, which makes it
automatically behave correctly when Hydra is accessed both directly
and behind a reverse proxy.
Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
Old intercaps names are aliased.
darcs-to-git: rename from darcsToGit
git-fast-export: rename from gitFastExport
git-remote-gcrypt: rename from gitRemoteGcrypt
hub-unstable: rename from hubUnstable
top-git: rename from topGit
Updates NixOS/hydra to the latest git-revision available. Also ensured
that the list of Perl dependencies needed for the server is up-to-date.
Most notably are the following changes:
* HTTP-endpoint at `/prometheus` to export metrics
* New user-roles for minor maintenance tasks
Hydra fails to start on recent recent nixpkgs due to a change in Perl packaging: this has been reported in #72783. @conferno in that thread suggested using lib.closePropagation as a fix, which is apparently deprecated, but works for now.
As Hydra doesn't have a release model, we have to pin git revs for our
package. The current state provides some new fixes and features like a status
plugin for GitLab.
As Nix 2.0 isn't bundled in `master` and `release-19.03` and we don't
support Nix 1.11 for Hydra, I figured that the Nix version checks could
be dropped and boost can always be used as build input.
Yesterday we had a discussion about several Hydra-related problems in the #nixos
IRC channel[1], as a result a lot of stalled PRs were merged.
I think that we want to use the latest Hydra now as it contains lots of
new fixes and folks mentioned that they want to use a self-hosted
Hydra, so they probably use the `nixpkgs` package rather than the
expressions from `NixOS/hydra`.
Simply moving to 2019-03-18 should be fine for now as Hydra doesn't have
a release model.
[1] https://logs.nix.samueldr.com/nixos/2019-03-17#2048416;
The component `hydra-evaluator` requires `pool.hh` from Nix which isn't
provided by Nix 1.x and thus fails with the following error in this
case:
```
hydra-evaluator.cc:3:10: fatal error: pool.hh: No such file or directory
#include "pool.hh"
^~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:443: hydra_evaluator-hydra-evaluator.o] Error 1
```
As the commit is from 2016 and fairly hard to revert for Nix 1.x
support, it's easier to drop that.
This has been tested with fixed perl-bindings for Nix1 as done in #55146.
This bumps Hydra to the latest revision available. As Hydra doesn't have
a release model (and therefore no tags) ATM, the derivation will pin
against the actual git revision and the date of the commit in the
derivation name.
Additionally the following changes have been made:
* Dropped `postUnpack` phase. It is useful when working with the Hydra
source (and no dirty changes shall be used in `release.nix`, but is has
no use in `nixpkgs`).
* Added myself as maintainer to have more folks available in case of
future breakage.
* Implemented support for Nix 2.0 and `unstable` (currently 2.1):
Since 1672bcd230447f1ce0c3291950bdd9a662cee974 in NixOS/nix the
evaluator differentiates between `settings` and `evalSettings`.
Previously `restrictEval` in `hydra-eval-jobs.cc` has been set in
`settings`, this doesn't work anymore in Nix 2.1 and is therefore
incompatible to Nix 2.0 on an API level.
To resolve this, the flag `isGreaterNix20` parses the version string
of `pkgs.nix` and applies a patch if nix.version<=2.0.
Furthermore the Hydra build with Nix 2.1 requires `boost` as build input
which is not needed for Nix 2.0. To avoid unnecessary increase in the
closure size this library will only used as build input for
nix.version>2.0.
* Fixed the NixOS test for `hydra`:
disabled binary cache to allow sandbox builds (otherwise it would
query `cache.nixos.org` during the Hydra build inside the test).
Additionally the trivial.nix jobset required simplification (as done
in NixOS/hydra, e.g. tests/api-test.nix) as bash is not available in
the build sandbox as builder (even when adding pkgs.bash to
systemPackages).
The easiest workaround to confirm a the functionality of a jobset
without importing nixpkgs is to use the default shell /bin/sh which
is mounted from `pkgs.busybox` into the build env
(https://github.com/NixOS/nixpkgs/pull/44841#discussion_r209751972) in the
VM and a named pipe to create $out.
Closes#44044
Rick van Schijndel