Pádraig Brady wrote:
> > @Padraig: you're at least doing some pre-release tests on several platforms,
> > but that's no real CI, is it?
> 
> Right.
> No real CI at present.
> It would be good though, directly for coreutils
> and indirectly for gnulib.

We have a CI for gnulib at Gitlab [1], but it detects only failures that are
covered by the unit tests, and — as you know — some of the complicated uses
of gnulib are only covered by coreutils tests, not by gnulib tests.

We have a CI also for a couple of GNU packages at Gitlab [2][3][4][5][6][7][8],
and they occasionally detect regressions. But with only 400 free CI minutes per
month [9], you couldn't have very many "expensive" test runs with coreutils
on that platform, even when using the coreutils mirror that someone already
has set up [10].

> I think I'll have a look at setting up
> some automated testing on the GCC compile farm.

Reading [11], it looks like this would be feasible, if you pick a machine that
has lots of CPU power and use 'ulimit' "to reduce the risk of a DOS attack".

I agree that it would be good.

Bruno

[1] https://gitlab.com/gnulib/gnulib-ci/-/pipelines
[2] https://gitlab.com/gnu-diffutils/ci-distcheck/-/pipelines
[3] https://gitlab.com/gnu-gettext/ci-distcheck/-/pipelines
[4] https://gitlab.com/gnu-grep/ci-distcheck/-/pipelines
[5] https://gitlab.com/gnu-gzip/ci-distcheck/-/pipelines
[6] https://gitlab.com/gnu-libunistring/ci-distcheck/-/pipelines
[7] https://gitlab.com/gnu-m4/ci-distcheck/-/pipelines
[8] https://gitlab.com/gnu-sed/ci-distcheck/-/pipelines
[9] https://about.gitlab.com/pricing/
[10] https://gitlab.com/saiwp/coreutils
[11] https://gcc.gnu.org/wiki/CompileFarm




Reply via email to