I observed too a few issues. One major one was that files can leak from the docker container into the host. Another is the complexity of uid/gid mapping and proper set up of a user home that matches the jenkins uid. But all in all not that hard to solve.
On 30 Oct 2017 7:11 p.m., "Joan Touzet" <[email protected]> wrote: > This is what Apache CouchDB does to auto-build .deb and .rpm Linux > packages. > > 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: > > https://github.com/apache/couchdb/blob/master/Jenkinsfile#L100-L112 > > 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. > > -Joan > ----- Original Message ----- > From: "Allen Wittenauer" <[email protected]> > To: [email protected] > 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 <[email protected]> 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 then. > > > > 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. > > +1 > > 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. >
