google
There doesn't seem to be a way to pass --architecture=i386 to CFLite
Some elfutils bugs manifest themselves only on 32-bit platforms like i386 or armhfp. They usually can be reproduced by simply compiling elfutils along with its fuzz targets with -m32 on 64-bit platforms like x86_64 but some bugs are spread across all architectures and to verify patches the code should be compiled with and without -m32. It's easy to miss something in the process (for example, in https://sourceware.org/bugzilla/show_bug.cgi?id=28715#c4 I didn't wait for the tests on 32 bit machines to finish and said the patches were OK). Luckily it was caught by that bespoke regression testsuite but I think testsuites like that shouldn't be neccessary when CFLite is used. It would be great if by analogy with sanitizer: ... it was possible to additionally pass something like architecture: i386 to CFLite.
Issues specific to 32-bit platforms popped up in the elfutils project and I've been using CFLite to test patches there so probably CFLite is more important to me than CIFuzz in this particular case. But it's kind of a temporary solution because elfutils isn't hosted on GitHub and their test infrastructure is based on buildbot for the most part. As far as I understand neither CIFuzz nor CFLite is compatible with custom test services like that so I'd probably put it on hold.
CFLite should be compatible with buildbot, you would just need to come up with a filestore that can be used. If buildbot doesn't have a way to persist files than we can use Google Cloud Storage or Amazon S3.
I don't think they'd consider using services provided by Google or Amazon. Their infrastructure including the mailing list, bug tracker and repository are based on open-source solutions having certain licenses that they manage themselves as far as I understand. Other than that I'm not sure they are open to docker. I think in January I'll have access to buildbot (in the sense that I'll be able to run tests there) and from there it should be possible to figure out what to do. That bespoke regression testsuite with a local driver and honggfuzz/afl seems to be what can be considered at least.
On the bright side, all the bugs the fuzz target has found have been fixed and CFLite has helped with catching regressions a lot
CIFuzz supports it (https://github.com/google/oss-fuzz/pull/7779) so with some duct tape I can point CIFuzz to my forks and use it. Closing.