On Mon, May 30, 2016 at 04:13:52PM +0530, Nigel Babu wrote: > 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 think this should contain the scripts from https://github.com/gluster/glusterfs-patch-acceptance-tests . Is that directory not a git repository? If so, just check with 'git remote -v'. > 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. Some of this is in the docs, but I do not know in what detail. Explaining more about it is surely good! Thanks, Niels > > On Mon, May 30, 2016 at 1:36 PM, Niels de Vos <ndevos@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
