----- Original Message ----- > From: "Mike Burns" <[email protected]> > To: "Kiril Nesenko" <[email protected]> > Cc: [email protected] > Sent: Wednesday, March 6, 2013 2:07:35 PM > Subject: Re: New git repo for jenkins > > On 03/05/2013 05:29 AM, Kiril Nesenko wrote: > > Hi all, > > I think that we need to create new git repo for jenkins in our > > gerrit. > > This git will store jenkins jobs configuration, scripts etc. > > Not opposed, but what does this do for creating or changing existing > jobs? Do we have to do it outside of jenkins? Do we simply make > changes in a git checkout, submit them, then they get pushed live > automatically?
Let me try to explain. Currently the status is all job logic is written inside the job itself, this is bad practise, for a few reasons: 1. no code review (job configuration is also only viewable and accessible to jenkins power-users/admins, not very "open source" approach) 2. difficult to include usage of files (answer file for example for automating engine-setup) 3. backup of code and revisions (sure there is the job config-history but that's really for troubleshooting the restoring jobs) 4. writing long complex code in bash/python inside a textbox is error prone and not convenient. I have experience from the past 2 years of writing code for jenkins jobs that got complex and longer as the product evolved. today i use even more than one repository for running jobs in jenkins. the proposed change is to keep all code inside a git repo instead just inside jenkins jobs. it doesn't mean that every job that has 2-3 lines of code should go into the git, it means we have a choice, if the code gets too complex (like running engine-setup + engine-upgrade) then we can use git as the source for the code. I intend to add some of the existing jobs that runs complex code into it, but not all of them. that's up to the job maintainer to decide. > > IOW, I think we need to map out exactly how things are supposed to > get > updated. I don't think we want people to have to change things in 3 > different places. We'll end up with some changes in git that aren't > in > the live jenkins, some that aren't in git, but are live. > > Also, what about new job development? Is that done through jenkins > and > then somehow exported into the git repo? New jobs can take many > iterations to get *right*. the way to use it in a job is by using the 'multiple scm plugin' which allows you to listen to more than one git repo for a job. you can see an example in the new setup+upgrade job knesenso is building now http://jenkins.ovirt.org/job/ovirt_engine_upgrade_stable_32_to_latest_32/configure > > I know I haven't been involved, but was something like this[1] > discussed > or evaluated? > > [1] > https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin as i mentioned, this plugin is good mainly for keeping track on who made change > > Mike > > > > > Thoughts ? > > > > Thanks, > > > > Kiril Nesenko > > Red Hat, Inc. > > > > www.redhat.com > > > > _______________________________________________ > > Infra mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/infra > > > > _______________________________________________ > Infra mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/infra > _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
