[Top][All Lists]

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

Re: CI

From: Flávio Cruz
Subject: Re: CI
Date: Tue, 5 Dec 2023 01:27:30 -0500

On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
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.


I have a simple CI setup in my cross-hurd github repository, see https://github.com/flavioc/cross-hurd/actions/runs/7080757561
It uses 4 different build configurations and it runs on my home server on a daily basis. I have sent quite a few patches throughout the last year or so because things would fail to build from time to time.
I run the same build harness whenever I have a new patch plus some manual testing (e.g., running qemu to see that things are not broken).

The issue is that I am building with my own scripts, so things are not configured like Debian GNU/Hurd or even using the same patches, but it's a good starting point - I think it's fine that we have multiple ways to build the Hurd.

Regarding my MiG patch generating warnings on glibc: I was looking into how I was building glibc and indeed I am passing --disable-werror. I had set this up many years ago so that explains what happened and sorry about that :) I need to go back to it, remove --disable-werror and generate the appropriate casts.

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]