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

[Nigel Babu]

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?
>
> --
> nigelb

I'm ready to make changes to Jenkins this week. I'm going to create a bot user
with access to modify jobs. This user will be used to run Jenkins Job builder.
The rest of us will all be demoted one level to being able to do everything but
modify or jobs. Everyone who currently has access will also have access to
run all jobs, so rebooting machines shouldn't be an issue.

Please let me know if this will block your work in anyway. If I don't hear
anything, I'll go ahead with this tomorrow morning.

--
nigelb