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