Edit: The last commit pushed out from hydra was the last commit from the
_previous week's_ roundup.
On Thu, Oct 20, 2016 at 7:05 AM Graham Christensen
wrote:
> Hi Jascha,
>
> After each vulnerability roundup (
> https://github.com/NixOS/nixpkgs/issues/19678 was from yesterday) I try
> to watch h
Hi Jascha,
After each vulnerability roundup (
https://github.com/NixOS/nixpkgs/issues/19678 was from yesterday) I try to
watch hydra and make sure they get released soon. The last commit pushed
out from hydra was the last commit from that roundup.
Yesterday we went through ~20 vulnerabilities, an
I'm also not sure if another Hydra instance would be the right way. On
the other hand, I would appreciate more frequent (security) updates for
NixOS 16.09. Currently, the channel stucks for over a week for whatever
reason...
Same applies for nixpkgs-unstable where tests randomly (?) fail too
which
What is the minimal replacement for Hydra. nix-build + dynamic remote
builders + nar s3 upload?
On Sun, 16 Oct 2016 at 18:53 Kevin Cox wrote:
> On 16/10/16 18:32, Shea Levy wrote:
> > I think an automated system would be nicer, but yes this would resolve
> > the majority of my concern here.
> >
On 16/10/16 18:32, Shea Levy wrote:
> I think an automated system would be nicer, but yes this would resolve
> the majority of my concern here.
>
I understand but I think Hydra works more then 95% of the time.
Designing an automated system for the rare case when we need to push an
emergency updat
I think an automated system would be nicer, but yes this would resolve
the majority of my concern here.
Kevin Cox writes:
> [ Unknown signature status ]
> On 16/10/16 18:24, Shea Levy wrote:
>> The existing infrastructure will always have more load and be more
>> complex than what is needed for
On 16/10/16 18:24, Shea Levy wrote:
> The existing infrastructure will always have more load and be more
> complex than what is needed for security updates. hydra is a fully
> general CI system, and properly so, but it means the system is subject
> to bugs and constraints that a simpler more focuse
The existing infrastructure will always have more load and be more
complex than what is needed for security updates. hydra is a fully
general CI system, and properly so, but it means the system is subject
to bugs and constraints that a simpler more focused system can avoid.
Moreover, for better or
-1 I think a better approach would be to bolster and support the existing
infrastructure and fix its issues, not create a whole new set. Hydra
already spins up and down AWS nodes depending on the number of jobs.
- https://github.com/NixOS/hydra-provisioner
-
https://github.com/NixOS/nixos-org-c