couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Sad state of Jenkins CI - please help fix our eunit tests!
Date Thu, 09 May 2019 19:04:38 GMT
I can help to create automated provisioning of the system with the help of Chef software.


02.05.2019, 23:48, "Joan Touzet" <>:
> Hi everyone,
> Lately, our Jenkins CI runs on master (after merges) have been failing a
> lot:
> Just in the last run (#537), we have failures in eunit tests for
> couch_mrview, mem3 and ddoc_cache that need active investigation. [1]
> Arguably, the reason no one is actively monitoring this and fixing the
> tests is because Jenkins does not (yet) gate commits from landing on master.
> This will change in the not-too-distant future. Travis CI has been
> slower and slower as of late, and with ownership/leadership change of
> Travis (the company) there's some trepidation in the community at large
> about its long-term survivability as well.
> IBM has graciously committed to a targeted hardware donation for build
> machines for our CI needs, to help us get runs done faster and in a
> controlled environment. I'll be working with them once that machine
> arrives to set up the new CI environment and ensure it does what we all
> expect. If anyone has any input on what that should look like, do reply
> to this email and let me know.
> Fixing Jenkins also will fix our broken snapshot package builds, which
> very soon *will include ARM64 support* that the community has been
> asking for, for a long time. Until we have regular greens on the board
> for ARM64, I'm not willing to approve greenlighting public packages or a
> Docker container for this platform. (Same goes for other platforms.)
> In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
> failing test, I can do that, let me know.
> -Joan "all green all the time?" Touzet
> [1]: The failure in 537 on CentOS 7 comes from my recent image rebuild,
> and CentOS's/EPEL's very recent decision to drop the python3 alias in
> favour of version-specific ones (python3.4, python3.6). I'll add a
> workaround for this via a /usr/local symlink in the image today.

View raw message