guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Project direction with testing changes (branches and patches)


From: Mathieu Othacehe
Subject: Re: Project direction with testing changes (branches and patches)
Date: Tue, 10 Aug 2021 08:04:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello Chris,

> I think trying to change up how branches (staging/core-updates) are
> tested is a good place to start. The concrete change I'm proposing is to
> use an instance of the Guix Data Service plus an instance of the Guix
> Build Coordinator to do the testing and builds, rather than Cuirass on
> ci.guix.gnu.org which is the current approach.
>
> The main advantages of that would be the comparison support from the
> Guix Data Service, and the build performance and reliability that the
> Guix Build Coordinator brings. The main disadvantage is probably the
> lack of an admin like interface similar to that of Cuirass (I think this
> can be remedied in the medium term though).

We indeed desperately need some more automation. For each new patch
series, it would be great to have the following information:

* Status of the linter.
* Status of the depending derivations.
* Status of the unit tests (in the tests/ directory).
* Status of the system tests (in the gnu/tests/ directory).

I would like to stay focused on the existing, well adopted solutions and
build upon them.  With Cuirass we already have most of the machinery to
provide those information.

In addition, we have dashboards, RSS and email notification support
which could allow us to extend Cuirass functionalities to provide the
expected CI features.

We could imagine a new API such as /api/changeset/new that would create
temporary Cuirass specifications. The output result could be consulted
using a new /api/changeset/status API or directly through the Cuirass
web interface. Cuirass could also send email and RSS notifications on
that changeset.

Those APIs could be used by Mumi to trigger the /api/changeset/new API
notification on one hand and to display some status using the
/api/changeset/status API on the other hand.

I think that this whole infrastructure is just a few Guile modules away
and if we could involve more fellow hackers in the process, it would be
just great.

Thanks,

Mathieu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]