That sure sounds nice. I frequently have problems with my slaves getting messed up and I have to clean them up. Do you have anything in github elsewhere?
-- Sami Rich Pixley <rich.pix...@palm.com> kirjoitti 31.7.2012 kello 0.23: > I'm not just thinking of using the source code control system to do the > cleaning here. > > I'm coming to jenkins after developing my own automated builder based on > btrfs snapshots. With btrfs snapshots, it's possible to both keep an old > build, (all artifacts intact), lying around while also creating a fresh > incremental build on top of it. The two builds then share files in the file > system so much as they are common and the file system takes care of which > ones stay around. > > With this approach, you can also automate recovery from failures. When an > incremental fails, you simply start the next incremental from the last > successful snapshot. This also allows for "pre-commit" checking in the sense > that changes can be built, (as an incremental on the previous build), and if > successful, the changes can be committed and the work space becomes the next > successful snapshot. If it fails, the next build starts from the previously > successful snapshot. > > This doesn't have the static disk allocation of jenkins, (one job, maximum > one workspace), but you can use the entire disk as a big ring buffer - remove > the oldest builds until there's enough space for the next build, then build. > > This is orders of magnitude faster than using the source code control system > to do the cleaning. It's also significantly faster in all work flows and > doesn't require any source code control system hooks at all. It's completely > source code control system agnostic. > > If you put btrfs on root, it also protects your build host by effectively > running the build in a disk jail. Builds can muck about with the state of > the build host and each build will still be completely independent with a > zero time setup cost. > > --rich
