couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <>
Subject Re: Sad state of Jenkins CI - please help fix our eunit tests!
Date Fri, 03 May 2019 08:32:17 GMT
Hi Joan,

I will be able to help later next week. If you could let me know of any
failing elixir tests I can start there.


On Thu, May 2, 2019 at 10:48 PM Joan Touzet <> wrote:

> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message