I'm not entirely clear about the role of puppet here. Where exactly does puppet fit in? AFAIK, the slave nodes can be dumb slaves that just do distro specific builds for us. They can be preconfigured and reused for each build. They don't even need to have jenkins installed on them. The slave.jar is just moved into the nodes directly by jenkins and it can track and monitor their state.
The packaging commands - dpkg, rpmbuild can then be run within slaves and artifacts can be copied back to master where they are hosted for download. I think this is how some of the projects build on http://build.apache.org where you can see distro specific slaves. +1 - on moving to jenkins controlled builds. External scripts should be replaced by jenkins plugins. There are a wide variety of them - SSH, git, mvn and even jClouds. -- Prasanna., On Mon, Sep 10, 2012 at 09:07:38PM -0400, Frank Zhang wrote: > > > > > > 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 > > > >
