New git repo for jenkins

[Eyal Edri]

----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "Kiril Nesenko" <kiril at redhat.com>
> Cc: infra at ovirt.org
> 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
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>