CI/CD in glibc (was: nss_db: protect against empty mappings)

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

12.07.2019 13:36 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> Rafal,
> 
> If you think this is a bad developer experience, then please feel
> free to voice your concerns.

This is little off-topic so I'm changing the subject of the
thread.

To some extent it is indeed a kind of bad experience.  In a perfect
world, every "make" run should rebuild all binaries whose source
code had changed and reuse those existing binaries from the previous
builds whose source code had not changed.  Usually this works fine
but sometimes does not.  In these rare cases "delete everything and
rebuild from scratch" is the correct answer.  I don't want to waste
my time and other developers' time to build a system where every
"make" works incrementally correctly because the aim is to ensure
that the rebuild from scratch works correctly because this is what
the distros are doing.  Incremental build is necessary only for our
small group of developers and, again, it works fine most of the time.

So maybe instead of focusing on incremental builds I should explain
why I perceive building as so important.  I always want to ensure
that my patches do not break glibc, including ensuring that they
don't break today (if yesterday everything was OK it does not mean
it is OK today because something might have changed upstream).
This is a simple and repetitive task which could be done automatically.

So the question is: can we have a CI/CD mechanism in glibc project
which would perform all builds and tests for every commit and raise
an alarm if anything goes wrong?  Can it be extended to verifying
patches when they are posted on this mailing list, before pushing
to the main repository?  Can it be part of sourceware.org, maybe
integrated with patchwork.sourceware.org?  Some big source code
management systems like GitHub or GitLab already include such
features, can we reuse them?  If not, can we have an unofficial
clone at GitHub (well, we already have one [1]) to do that task?

Such a mechanism would be useful to detect use cases like:
* something goes wrong but the problem is only in my machine
  because the online service confirms there is no problem;
* the code works fine in my machine and in all other developers'
  machines but fails in one exotic hardware architecture.

Regards,

Rafal

[1] https://github.com/bminor/glibc/