> -----Original Message----- > From: Frank Zhang > Sent: Monday, September 10, 2012 4:52 PM > To: Edison Su; [email protected] > Cc: Pradeep Soundararajan > Subject: RE: Discuss on the Jenkins CI > > 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. > > > -----Original Message----- > > From: Edison Su > > Sent: Monday, September 10, 2012 4:34 PM > > To: Frank Zhang; [email protected] > > 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; [email protected] > > > 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: [email protected] > > > > 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
