[Top][All Lists]

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

Re: CI

From: Samuel Thibault
Subject: Re: CI
Date: Sun, 3 Dec 2023 02:29:51 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Yes, sure, anything will do.

I essentially mean that "we" shouldn't be me.

For a start, just testing that the whole thing just builds in the
various situations would be a *VAST* improvement, considering the amount
of time I spend on just that.

Then there was recently some work on building simple userland tests,
that can be easily tested as well.

Essentially, any regression that people usually find ("doesn't build",
"doesn't boot", etc.) is worth testing. That can also be simply running
the glibc testsuite in the resulting build.


Almudena Garcia, le dim. 03 déc. 2023 01:20:58 +0000, a ecrit:
> As a little suggestion, using my very little knowledge about it, we can set a 
> mirror in a GitLab server, which incorporates this functionality natively. We 
> can deploy a GitLab local server if we don't want to depends of gitlab.com, 
> and set a couple of tests in it.
> As this way, we can use a testing branch in the GitLab server to merge the 
> changes and execute the tests automatically from it before applying it over 
> Savannah's upstream. 
> Maybe even we can configure any task to push the changes in Savannah if they 
> pass the tests.
> Obviously, the first what we need is to discover what tests are necessary to 
> execute to be sure that all the changes works properly.
> What do you think?  
> El domingo 3 de diciembre de 2023, Samuel Thibault escribió:
> > Can some people eventually set up some CI somehow somewhere?
> > 
> > (AFAIK savannah doesn't support such a thing, so it wouldn't go there,
> > so anybody can feel free to set it up wherever it sees easiest).
> > 
> > If people wonder why I don't make releases that often, the reason is
> > very simple: each time I try to do one, I end up spending *hours* in
> > fixing various build failures and runtime failures, because things are
> > not tested properly. And I'm not saying that *people* are not testing
> > properly, because there are so many various cases that can break (32,
> > 64, 32-on-64, acpi, non-acpi, smp, non-smp, Xen, etc.). So we do need
> > automated testing, otherwise that just burns my time.
> > 
> > Samuel

reply via email to

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