[Gluster-devel] [Gluster-infra] Access to Jenkins

[Nigel Babu]

On Thu, Jun 16, 2016 at 12:29:24PM +0200, Niels de Vos wrote:
> On Wed, Jun 15, 2016 at 09:14:16PM +0530, Nigel Babu wrote:
> > Hello folks,
> >
> > We have 45 people who have access to Jenkins UI. Pretty much everyone will be
> > losing this access in the next couple of weeks.
> >
> > At the moment, I understand that access to the UI is essential for configuring
> > jobs. I’m going to change this in the near future. Jenkins Job Builder[1] will
> > talk to Jenkins to create/update jobs. Job information will be managed as a
> > collection of yaml files. If you want a new job, you can give us a pull request
> > with the correct format. The jobs will then be updated (probably via Jenkins).
> > You will then no longer need access to Jenkins to create or manage jobs. In
> > fact, editing the jobs in the UI will make the YAML files out of sync.
> >
> > Before we start this process, I’d love to know if you use your Jenkins access.
>
> Initially it was only possible to start regression tests by logging into
> Jenkins and running the job manually. There were fewer patches and the
> duration of the job was much shorter too.
>
> Later on, we got more slaves and longer running regression tests.
> Someone configured the Jenkins jobs to get triggered on each change that
> was posted (now modified to only run after Verified=+1). This caused a
> lot of weird side-effects, including tests failing more regularly for
> unknown reasons. Retriggering a job was only possible by clicking the
> "retrigger" link in the Jenkins webui (now we can do so with "recheck
> ..." in Gerrit comments).
>
> Sometimes regression tests cause a fatal problem on a slave. The only
> way to get the slave back, could be through a hard reboot. The reboot-vm
> job in Jenkins made that possible. The job prevented people from
> requiring a Rackspace account.
>
> Release tarballs are created through Jenkins. Anyone doing releases
> should have their own Jenkins account to run the job.
>
> I think many of the maintainers should be able to run at least the
> release job. Configuration of the jobs can be restricted, specially if
> Jenkins Job Builder is used. Somewhere in the Contributors Guide there
> should be a description on how to make changes to the Jenkins jobs. I've
> never used JBB and definitely need some assistance with it.
>   http://gluster.readthedocs.io/en/latest/Contributors-Guide/Index/
>
> HTH,
> Niels
>
>
> > If you do use it, please let me know off-list what you use it for.
> >
> > [1]: http://docs.openstack.org/infra/system-config/jjb.html
> >
> > --
> > nigelb
> > _______________________________________________
> > Gluster-infra mailing list
> > Gluster-infra at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-infra

Hi Niels,

This is more complex than I thought, I won't be doing *anything* immediately.
I'll take some time to get configuration right so we don't accidentally end up
in a place where nobody can get work done.

I'm going to slightly change what I originally intended:
1. We will still go ahead with Jenkins Job Builder. It has reasonably good
   documentation, but I'll be available to help in case anyone is stuck. I will
   convert the existing jobs into yaml format for jjb, so they will serve as an
   example. I'll make sure our documentation has a section for how to write
   jobs. Context: JJB was written by Openstack infra team who also use Jenkins
   and Gerrit, so it shouldn't give us too much trouble.
2. The VM restart is an interesting problem that I didn't have insight into
   before. I'm happy to grant current developers access to have access to the
   restart job (We have to define "current developers" at some point).
   Eventually, I hope to make it less of a problem by restarting after every
   X number of jobs, restarting after a failure, or some such (we can talk
   about this later).
3. For release jobs, I'll similiarly create a group who will have full access
   to that job. This way I won't be blocking work while we look at better
   options.

Does this solve our immediate concerns?

--
nigelb