www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: Jenkins slave able to build BED & RPM
Date Mon, 30 Oct 2017 18:11:39 GMT
This is what Apache CouchDB does to auto-build .deb and .rpm Linux

All the details are in the Jenkinsfile in our main repo, along with
the companion couchdb-ci and couchdb-pkg repos for support files.

Start here:


It took a bit of work to get the containers set up correctly, and
we worked hard with Infra to get the worker nodes running in a
stable fashion, but it hums along with minimal intervention now.

----- Original Message -----
From: "Allen Wittenauer" <aw@effectivemachines.com>
To: builds@apache.org
Sent: Monday, 30 October, 2017 1:58:18 PM
Subject: Re: Jenkins slave able to build BED & RPM

> On Oct 30, 2017, at 4:33 AM, Dominik Psenner <dpsenner@gmail.com> wrote:
> On 2017-10-30 11:57, Thomas Bouron wrote:
>> Thanks for the reply and links. Went already to [1] but it wasn't clear to me what
distro each node was (unless going through every one of them but... there are a lot) As you
said, it seems there isn't a centos or Red Hat slave, I'll file a request to INFRA for this
> You also have the option to run the build with docker on ubuntu using a centos docker
image. I think it would be wise to evaluate that option before filing a request to INFRA.
The great benefit is that you can build an rpm and test a built rpm on all the rhel flavored
docker images that you would like to support without the requirement to add additional operating
systems or hardware to the zoo of build slaves.


	Despite the issues[*], I’m looking forward to a day when INFRA brings the hammer down and
requires everyone to use Docker on the Linux machines.  I’ve spent the past week looking
at why the Jenkins bits have become so unstable on the ‘Hadoop’ nodes.  One thing that
is obvious is that the jobs running in containers are way easier to manage from the outside.
 They don’t leave processes hanging about and provides enough hooks to make sure jobs are
getting a ‘fair share’ of the node’s resources. Bad actor? Kill the entire container.
Bam, gone. That’s before even removing the need to ask for software to be installed. [No
need for 900 different versions of Java installed if everyone manages their own…]

* - mainly, disk space management and docker-compose creating a complete mess of things.

View raw message