[Gluster-devel] Understanding build.jenkins.org

Nigel Babu nigelb at redhat.com
Mon May 30 10:43:52 UTC 2016


Hi Niels,

Thank you. This gives me a much clearer picture than what I had with simply
exploring the Jenkins web UI and the server. I still have a few more
questions:

What is /opt/qa. Where is that code coming from?

I'm guessing that a lot of this isn't written down. So I'm going to make an
effort to document the current state as is in the Ops-Guide section of the
documentation.

On Mon, May 30, 2016 at 1:36 PM, Niels de Vos <ndevos at redhat.com> wrote:

> On Mon, May 30, 2016 at 10:21:27AM +0530, Nigel Babu wrote:
> > Hello folks,
> >
> > I'm trying to get a sense of how our Jenkins instance. In particular, I'm
> > trying to understand the following:
> >
> > 1. How jobs are created. Is this version controlled or automated in any
> > manner?
>
> The jobs are created in the Jenkins webui, and later exported with the
> Jenkins CLI (https://build.gluster.org/cli). The resulting XML files are
> stored here:
>
> https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/jenkins/jobs
>
> > 2. How are the machines created? Do we have a standardized image?
>
> No idea, Micheal Scherer should know. I guess Manu setup the NetBSD
> systems, not sure who takes care of the FreeBSD ones.
>
> > 3. Where is the code (the repository) for the tests that are run?
>
> Most of the tests have their scripts in the patch-acceptance-test
> repository:
>   https://github.com/gluster/glusterfs-patch-acceptance-tests
>
> The regression tests themselves are contained in the glusterfs
> repository. We expect that all changes to the sources come with a
> test-case.
>
> > 4. What is the process for going from updating the code for a test to
> > updating the job on Jenkins? Is this automated and/or documented?
>
> Not sure. The number of people that modify the Jenkins jobs is very
> small. All of them are aware (or should be!) that a modification
> requires updating the XML files in the git repo.
>
> > 5. How many of the jobs are critical?
>
> All of the regular running ones?
>
> > 6. What is the process for creating new jobs/new types of tests?
>
> That is hardly ever needed, and more of an exception. If someone needs a
> new job on build.gluster.org one of the people with an account can
> create it.
>
> > Bonus Question: Is there any friction that you'd like to see us reduce?
>
> One of the things we're doing for this is to move more time consuming
> and multi-host tests to ci.centos.org. Currently the regression tests
> are still running on our own instance, but the CentOS CI has much more
> and much faster hardware (no VMs). There is the long-term plan to move
> at least a bunch of the heavy testing to their Jenkins instance.
>
> Also scheduled jobs (distaf tests, tests for integration with other
> projects, nightly builds, ....) are supposed to get added to the CentOS
> CI, and not our build.gluster.org environment:
>   https://ci.centos.org/view/Gluster/
>
> Thanks,
> Niels
>



-- 
nigelb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160530/a3a5b818/attachment.html>


More information about the Gluster-devel mailing list