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@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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
