Well, this is the script from hell... newImage.sh doesn't executes the last line:
# ---------------------------------------------------------------------------- # try to open the image... set -e openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" because openImage exits the script... Question: can't we run all of this headless? Phil 2013/2/16 Marcus Denker <[email protected]>: > > On Feb 16, 2013, at 1:57 PM, Ben Coman <[email protected]> wrote: > >> Marcus Denker wrote: >>> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[email protected]> wrote: >>> >>> >>>> Hi, >>>> >>>> Finally, with a lot of work, mana, power cards and jedi tricks, we made >>>> the pharo vm builds work again :) >>>> >>>> This builds are up-to-date with latest sources from Eliot's cog and adds >>>> pharo branding (AFAIK, this is the first time we are going to release >>>> something like that :) >>>> >>>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>>> >>>> >>> >>> Very good! >>> >>> So now we need to step by step.. >>> -> use the build in the one-click >>> -> link the VM zips on pharo-project.org >>> -> replace the VM we use for running jobs on jenkins with this. >>> >>> And of course: >>> -> test those builds on all three architectures automatically with a >>> test image (e.g. current 2.0 with all failing tests removed) >>> The idea is that this image should not change frequently (the >>> only variable is the VM) >>> >> Could the CI test new VMs against all previous "release" images eg Pharo >> 1.3, 1.4, 1.4 Summer, 2.0, 2.x >> or some subset, like the last release of each major version. While you may >> not want a very old release to fail a VM, at least the compatibility would >> be on record. > > One idea we had was to give up the "all VMs need to run all images", because > this makes it very hard to move… > > Marcus > > >
