Thanks for the officer, Serge, but unless you're an IBM employee, you
won't be allowed to help!
Because IBM is providing the hardware, they are also taking
responsibility for provisioning the Jenkins workers on that box. This
was a condition of them providing the machine: that they would retain
full control outside of Jenkins, and wouldn't be providing credentials
to others. They already have their own automated provisioning
infrastructure (which, coincidentally, is Chef-based) and team to manage
it. IBMers, speak up if I'm wrong here.
Our CouchDB build process for Jenkins runs in Docker containers as
defined over here:
https://github.com/apache/couchdb-ci
and is driven by the top-level Jenkins file in the CouchDB main repo.
This is how we avoid having to manage CouchDB dependencies on the
Jenkins hardware, and makes the job of provisioning Jenkins workers a
**LOT** easier. (They just need to install Docker, Java, Jenkins, qemu,
and a couple of other support packages, plus deploy the Jenkins secret
that allows each worker to register with the ASF's build master. Simples.)
If you have suggestions for improvement on the CouchDB CI repo, or want
to help with expanding it to support other configurations, pull requests
are always welcome. :D
Cheers,
Joan "moar CI" Touzet
On 2019-05-09 15:04, salsa-...@tut.by wrote:
> I can help to create automated provisioning of the system with the help of
> Chef software.
>
> Serge
>
> 02.05.2019, 23:48, "Joan Touzet" <jo...@atypical.net>:
>> Hi everyone,
>>
>> Lately, our Jenkins CI runs on master (after merges) have been failing a
>> lot:
>>
>> https://s.apache.org/yuwY
>>
>> 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.
