From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: GSoC: Adding a web interface similar to the Hydra web interface Date: Wed, 6 Jun 2018 20:02:10 +0200 Message-ID: <20180606200210.7a9c4dd6@scratchpost.org> References: <87vac3twbe.fsf@gnu.org> <87o9hog2ye.fsf@elephly.net> <87d0xyn9zs.fsf@elephly.net> <87d0xswvls.fsf@elephly.net> <87r2m4ntk4.fsf@mdc-berlin.de> <87tvqxy4i9.fsf@elephly.net> <87in78hxo2.fsf@elephly.net> <878t7xb58o.fsf@elephly.net> <874lijbqvf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Y06aHUYDOrAsZ82PJ2xD5yB"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQclW-0001yD-Ke for guix-devel@gnu.org; Wed, 06 Jun 2018 14:02:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQclT-0007mg-G4 for guix-devel@gnu.org; Wed, 06 Jun 2018 14:02:34 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:52928) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fQclT-0007d6-86 for guix-devel@gnu.org; Wed, 06 Jun 2018 14:02:31 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Tatiana Sholokhova Cc: guix-devel --Sig_/Y06aHUYDOrAsZ82PJ2xD5yB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Tatiana, > I afraid that I am not familiar with typical Hydra use cases Generally, the continuous integration process should enable developers to get feedback about the effects of their changes. This means that as soon as a commit is made, usually an evaluation of the build source on the continuous integration server starts. (Sometimes there are exceptions to this (for example in order to not overlo= ad the build servers) - but generally it's true) For a new evaluation, as a developer I'd like to know: * Are now more packages broken than before? Which ones? * Are now more packages working than before? Which ones? * Do some packages work on more architectures than before? Fewer? * Is the build server still building my change? Or is it done and I can trust that the information I see is now complete? If not, what is it building now or later? "before" means "with the previous evaluation" or "with some specific past evaluation" or "in another branch". I think this would be the most basic functionality. More advanced functionalities would include automatic tracking on the reason of the failure: * If it's dependency failure, specifically mark this package so I know I do= n't have to fix this package - I have to fix a package this one depends on (whi= ch one?). * What kind of failure is it? What's the latest non-noise error message in = the build log? Display suggestions on what to do about it. What do you think? >4. Add additional information about previous builds (latest successful, >first broken, etc) on this build page. For this feature, we need to extend >database requests functionality. Sounds good. --Sig_/Y06aHUYDOrAsZ82PJ2xD5yB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlsYIaIACgkQ5xo1VCww uqUKkAf/WmPrlDa4TwbQlV1xWTBaoEOgAk3bJ/HJouMzaZ9OiriQM3Ignfwmsj0A 2ZBeEhMFw0pOA9ex4JxlR2YxjVTOokbNWDzcT2qGUh+m4vTl+Cx5DwH/E40IxWpb FCQ1SHLyCNyctoWs5jD8KEb8xshOBw9Ija0wLVgwDbGh28mA5un9V/6kIoc6UFub pcuQVoAlINAYoEtLKJJTTrPsD8XVo/S3iBJsRHIsXmTo+A3fIVCB0aRY1RTzGhL5 oIQIM11JIXbaxZ6KiJcosyrEvyvKkGIQu7A2SOaUW7ZMDZxcaGbT8RSijTZ/ND92 n9U1jyHSDYysXTbuVMRvFJ0we5npXw== =6oTZ -----END PGP SIGNATURE----- --Sig_/Y06aHUYDOrAsZ82PJ2xD5yB--