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

[Niels de Vos]

On Thu, Jun 16, 2016 at 04:58:52PM +0530, Nigel Babu wrote:
> 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?

Sure! It is not so much concerns, just explaining how Jenkins is
currently used :)

I think there are other Gluster-related projects (like libgfapi-python)
that run in build.gluster.org. Not sure if their workflow matches what I
described above.

Cheers,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160617/6098cf58/attachment.sig>