Discussion:
help needed for continuous integration
(too old to reply)
Bruno Haible
2018-02-04 10:20:39 UTC
Permalink
Raw Message
Hi all,

If you are familiar with Travis CI or Appveyor CI, please help keeping gnulib
at a high quality!

It is normal for a developer to push a buggy commit by mistake. But it should
not be normal that such a mistake, that leads to a test failure on standard
glibc systems, remains unnoticed for 10 days.

It would be good to have a continuous integration (Travis or Appveyor, I
don't mind) of gnulib, to detect test failures early.

There is already a github mirror of the gnulib git repo, at
https://github.com/coreutils/gnulib, and it is apparently kept up-to-date
automatically.

The continuous integration should probably run these commands:
$ ./gnulib-tool --create-testdir --dir=/some/testdir --single-configure \
--with-c++-tests --without-privileged-tests
$ cd /some/testdir
$ make
$ make check

Please speak up and help!

Bruno
Tim Ruehsen
2018-02-04 10:31:36 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi all,
If you are familiar with Travis CI or Appveyor CI, please help
keeping gnulib
at a high quality!
It is normal for a developer to push a buggy commit by mistake. But it should
not be normal that such a mistake, that leads to a test failure on standard
glibc systems, remains unnoticed for 10 days.
It would be good to have a continuous integration (Travis or
Appveyor, I
don't mind) of gnulib, to detect test failures early.
There is already a github mirror of the gnulib git repo, at
https://github.com/coreutils/gnulib, and it is apparently kept up-to-
date
automatically.
$ ./gnulib-tool --create-testdir --dir=/some/testdir --single-
configure \
--with-c++-tests --without-privileged-tests
$ cd /some/testdir
$ make
$ make check
Hi Bruno,

I have CI experience with several projects and I am willing to help.

From my experience and knowledge, the Gitlab CI is much more
configurable than e.g. Travis. It is docker based and thus limited to
all kinds of Linux variants (including cross-platform builds, e.g.
MinGW). Therefore I use Travis for OSX testing only.

I have no experience with AppVeyor wich would be useful for native
Windows testing.

As a starter, I could set up a gnulib test CI as a subproject in https:
//gitlab.com/gnuwget that syncs+tests gnulib e.g. once a day.

WDYT ?

Regards, Tim
Bruno Haible
2018-02-04 12:29:57 UTC
Permalink
Raw Message
Hi Tim,
Post by Tim Ruehsen
I have CI experience with several projects and I am willing to help.
Cool!
Post by Tim Ruehsen
From my experience and knowledge, the Gitlab CI is much more
configurable than e.g. Travis. It is docker based and thus limited to
all kinds of Linux variants (including cross-platform builds, e.g.
MinGW). Therefore I use Travis for OSX testing only.
I have no experience with AppVeyor wich would be useful for native
Windows testing.
Good, agree with Gitlab CI as a starter (since glibc systems are the
most important platforms to test).
Post by Tim Ruehsen
//gitlab.com/gnuwget that syncs+tests gnulib e.g. once a day.
I think it would be better to register https://gitlab.com/gnulib as a new
project. (In the long run, the intersection between wget maintainers and
gnulib maintainers may be empty.) Would you be willing to do that, please?

"syncs+tests gnulib once a day" sounds good.

Bruno
Tim Ruehsen
2018-02-04 15:32:23 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi Tim,
Post by Tim Ruehsen
I have CI experience with several projects and I am willing to help.
Cool!
Post by Tim Ruehsen
From my experience and knowledge, the Gitlab CI is much more
configurable than e.g. Travis. It is docker based and thus limited to
all kinds of Linux variants (including cross-platform builds, e.g.
MinGW). Therefore I use Travis for OSX testing only.
I have no experience with AppVeyor wich would be useful for native
Windows testing.
Good, agree with Gitlab CI as a starter (since glibc systems are the
most important platforms to test).
Post by Tim Ruehsen
//gitlab.com/gnuwget that syncs+tests gnulib e.g. once a day.
I think it would be better to register https://gitlab.com/gnulib as a new
project. (In the long run, the intersection between wget maintainers and
gnulib maintainers may be empty.) Would you be willing to do that, please?
"syncs+tests gnulib once a day" sounds good.
Hi Bruno,

basically set up a minimalistic group and two projects. One project to
build the docker images, another one to fetch gnulib and test it.

The stretch CI image is already built, the testing CI still waiting to
be processed.

Meanwhile you should create a Gitlab account and tell me your nick. So
I can invite you and give you the appropriate permissions.

There is much to be tuned (permissions, build optimizations, different
kind of builds/tests e.g. with/without sanitizers). And there is much
to learn about the Gitlab UI.
Maybe it's better to discuss those details via PM - feel free to
contact me.

Regards, Tim

Loading...