On 03/06/2013 08:54 AM, Eyal Edri wrote:
----- Original Message -----
> From: "Mike Burns" <mburns(a)redhat.com> To: "Kiril Nesenko"
> <kiril(a)redhat.com> Cc: infra(a)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:
Not all, but most (ovirt-node-iso* jobs runs a script file in it's
source repository). The logic in the jenkins job is simply clean up and
run.
1. no code review (job configuration is also only viewable and
accessible to jenkins power-users/admins, not very "open source"
approach)
Agreed, though we can easily make the code read-only to non-power-users.
2. difficult to include usage of files (answer file for example for
automating engine-setup)
I haven't encountered this issue. I've had jobs before (though not in
upstream oVirt) that pulled files from other jobs for this purpose. For
example, a job that generates a file like "releases.txt" that contains
mappings for something like "FDEVEL=19" FRELEASED=18", etc. which are
then sourced in the other job
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 agree about writing code in a textbox like that, it's not ideal. I
generally copy it out, edit it in an editor of my choice, then copy it
back in.
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.
OK, I think that's the right choice. I expect many jobs are simple
automake builds that do thinks like:
./autogen
make
make install
make rpms
maybe with some slight changes. If there are more complex jobs, then
yes, moving the code into something like git is probably worthwhile. It
might not be necessary for ovirt-node to have a maintainer on the git
repo though. I think our jobs are relatively simple enough to not need it.
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/...
OK, I can see how that works. I hadn't tried it previously.
>
> 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
OK, I haven't used it, was just making sure we weren't re-inventing the
wheel.
>
> Mike
>
>>
>> Thoughts ?
>>
>> Thanks,
>>
>> Kiril Nesenko Red Hat, Inc.
>>
>>
www.redhat.com
>>
>> _______________________________________________ Infra mailing
>> list Infra(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/infra
>>
>
> _______________________________________________ Infra mailing list
> Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
>
_______________________________________________ Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra