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