> On 24 Oct 2014, at 00:50, Luc Fabresse <luc.fabre...@gmail.com> wrote: > > Hi, > > Note that zeroconf handlers allow you to build images incrementally (the > image is saved after each build), which is way faster than always starting > from scratch. > > what are zeroconf "handlers"? > because I use zeroconf to rebuild images and it is slow because it downloads > the vm, the image, the mcz then installing, ... > did I missed something?
1. Setup a build directory/image $ mkdir build $ cd build $ curl get.pharo.org/30+vm | bash $ ./bin/pharo -vm-display-null Pharo.image save build 2. Load/update your stuff $ ./bin/pharo -vm-display-null build.image config http://mc.stfx.eu/XYZ XYZ --install=bleedingEdge --username=s...@beta9.be --password=secret $ ./bin/pharo -vm-display-null build.image save t3 You do step 1 only once, you can repeat step 2 many times. It uses the build.image and the local package-cache as a cache, incrementally adding only those things that changed. Try it, it is way faster. You can always reset and start over if you think that is necessary but it rarely is. > thx, Sven and Esteban, I like reading development and deployment processes > from experienced people! > > #Luc > > > > After a year o Pharo development I think I'm ready to embrace a CI > > server (I already use scripts to build images), but I think I will > > move all my repositories to git before. > > These are orthogonal decisions, most CI jobs on the Pharo contribution server > run against StHub. > > > However, my remote server provisioning is still manual, and too > > rudimentary even for my own taste. If I could speed up this, I would > > deliver features faster to my customers. Now everything runs inside a > > two week sprint window. > > I am not into provisioning myself, but more automation is always good, though > sometimes setting up and maintaining all these things takes a lot of time as > well. > > > Regards, > > > > Esteban A. Maringolo > > <filelocator.png> > > >
