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