| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The isHydraChannel meta attribute is needed in order to tell Hydra that
the derivation in question should be a channel tarball. However in
Nixpkgs the meta attribute is not used, so checkMeta doesn't recognise
it as a valid attribute which leads to an evaluation error.
Recently[1] a commit got merged, which enables shallow type checking for
meta attributes by default. This led to an evaluation error for our
Hydra machine channels for the reason mentioned above.
I opted to work around that issue by adding meta.isHydraChannel after
mkDerivation, because adding isHydraChannel as a valid meta attribute to
Nixpkgs doesn't feel right to me since it's only relevant for Hydra and
its apparently deprecated[2] channel feature.
[1]: https://github.com/NixOS/nixpkgs/commit/6762de9a28e248f46bd0810e03c
[2]: https://github.com/NixOS/hydra/blob/53335323ae79ca1a42643f58e520b376898ce641/doc/manual/src/jobs.md#meta-fields
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 65435d827c846ab2eef966601cd0490591b8dbe9.
Commit d730df7 fixed the meta.hydraPlatforms attribute, so the generic
channel now should build the patched gitit version as part of its
constituents and we don't need a dummy machine just for that anymore.
Other than that, the package now also gets built as a separate job to
allow for one-click installs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @Profpatsch
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to 302fb4f4bc0213b231b9bf5b98093c60d3917313 the package should
be included in the hydra build, but it is not usable, because there is
no channel that waits for the gitit build to succeed.
This stub exists until someone finds out how to create such a
channel (aka the channel building mechanism is documented in a way that
it can be used by people not deeply familiar with both nixpkgs and
hydra).
cc @aszlig
|
| |
|
|
|
|
|
|
| |
It's kinda pointless to shovel the whole source to a remote machine and
then shovel the whole source back to the Hydra master without doing any
real compiling or other CPU-intensive processing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
The problem here was that the attributes were added to the resulting
derivation of mkDerivation instead of the input attribute set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
| |
Should make it easier to patch the channel expressions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
In the latest not-yet-public implementation of Hydra channel
improvements, we now have a meta attribute to designate a channel.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
This is because I've changed the the WIP implementation to use a product
type instead of a subtype.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
The third argument in hydra-build-products is actually the base
directory and not a name, Alzheimer's near!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
We're going to create several channels and we don't want to code
duplicates across vuizvui. This essentially not only creates a channel
but also ties it to constituents, which make sure that channels are only
updated whenever all constituent builds are successful.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
