> > > > I thought we should use puppet anyway for future expansion. > > For now, for instance, installing Jenkins itself should be done by > > puppet, adding ssh credential, adding an account, and whatever system > > configuration works. > > What I expect is we only spring up a vm with puppet agent installed, > > puppet master takes care of rest work (no manually 'yum install > > Jenkins' anymore) And puppet should go to our test system in future as > > well, so now let's take this chance to make puppet warm up. > > > It's ok to warm up puppet, but the build is more important. For example, we > need to customize the version number, or the name of the > artifcates(rpm/deb), it's better to move to new Jenkins, other than hacking > on the existing python code.
We can do that. Just step by step. As setting up puppet is easier, let's do it first. Next week I think we can move to Jenkins plugins > > > > > > -----Original Message----- > > > From: Edison Su > > > Sent: Monday, September 10, 2012 4:34 PM > > > To: Frank Zhang; cloudstack-dev@incubator.apache.org > > > Cc: Pradeep Soundararajan > > > Subject: RE: Discuss on the Jenkins CI > > > > > > If we use jenkins plugins, then there is not much we need to do with > > puppet. > > > Only need to run this plugin: https://wiki.jenkins- > > > ci.org/display/JENKINS/Slave+Setup+Plugin > > > > > > > -----Original Message----- > > > > From: Frank Zhang > > > > Sent: Monday, September 10, 2012 4:01 PM > > > > To: Edison Su; cloudstack-dev@incubator.apache.org > > > > Cc: Pradeep Soundararajan > > > > Subject: RE: Discuss on the Jenkins CI > > > > > > > > I agree we should leverage existing infrastructure of Jenkins. > > > > But I suggest first making our build machines by puppet, then > > replace > > > > the build system with Jenkins' plugins > > > > > > > > > -----Original Message----- > > > > > From: Edison Su > > > > > Sent: Monday, September 10, 2012 3:45 PM > > > > > To: cloudstack-dev@incubator.apache.org > > > > > Cc: Pradeep Soundararajan; Frank Zhang > > > > > Subject: Discuss on the Jenkins CI > > > > > > > > > > We have a working Jenkins on http://jenkins.cloudstack.org/, > > which > > > > can build > > > > > RPM/DEB. > > > > > It looks like we are using Jenkins, but actually, underneath, we > > > > don't leverage > > > > > the powerful plugins provided by Jenkins. From the > > > > > documents(https://wiki.jenkins-ci.org/display/JENKINS/Plugins), > > > > Jenkins > > > > > provides all kinds of plugins we can customize during the > > lifecycle > > > > > a > > > > build, > > > > > which should be enough for us. Meaning it's possible to get rid > > of > > > > > https://github.com/CloudStack/hudsonbuild, use > > plugins(slave/master, > > > > git, > > > > > maven, ant, s3 etc) of Jenkins instead. > > > > > The benefit of this move: > > > > > 1. Jenkins is good at scheduling jobs, all the operation we > > are > > > > doing can be > > > > > put into jobs: e.g. If need to cleanup storage on one of build > > > > machine, > > > > > schedule a job on that machine, then execute a shell script to > > clean > > > > up. It's > > > > > the same thing for a build. > > > > > 2. Maintainable, there should be no extra code needed to put > > > > > into > > > > build > > > > > machines, all we need is to configure on Jenkins UI. So > > > > > everybody can customize the build. > > > > > > > > > > And later on, we can integrate automate test into Jenkins, using > > > > cloudstack > > > > > to preinstall baremental machines: > > > > > http://code54.com/blog/2012/09/08/cloud-provisioning-for-ci- > > jenkins- > > > > > cloudstack.html
