[Pharo-project] Pharo vm builds restored
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/ Enjoy, Esteban & Igor
On 2013-02-15, at 18:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :)
coool! I hope you kept trace of all the things you have to modify!
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/
I made it upload to the gforge again, so the latest builds we be there as well: http://pharo.gforge.inria.fr/ci/vm/pharo/
Cool! Downloaded the OSX one. Works! Phil 2013/2/15 Esteban Lorenzano <estebanlm@gmail.com>:
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/
Enjoy, Esteban & Igor
Things you should know: - all VMs including: OSProcess plugin SSL Plugin (bundled with ssl library for win32) NB Plugin Freetype (bundled with freetype library for win32 & mac) bundled with Cairo library (win32 & mac) linux VMs don't needs to be bundled, since you can install those libs from their corresponding distros. -- Best regards, Igor Stasenko.
thanks igor and esteban. Stef On Feb 16, 2013, at 12:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Things you should know:
- all VMs including: OSProcess plugin SSL Plugin (bundled with ssl library for win32) NB Plugin Freetype (bundled with freetype library for win32 & mac) bundled with Cairo library (win32 & mac)
linux VMs don't needs to be bundled, since you can install those libs from their corresponding distros.
-- Best regards, Igor Stasenko.
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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) -> only when this is green the zip is updated in the archive Marcus
On 16 February 2013 10:24, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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) -> only when this is green the zip is updated in the archive
yes. we should test new artifacts.
Marcus
-- Best regards, Igor Stasenko.
Marcus Denker wrote:
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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.
-> only when this is green the zip is updated in the archive
On Feb 16, 2013, at 1:57 PM, Ben Coman <btc@openInWorld.com> wrote:
Marcus Denker wrote:
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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
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 <marcus.denker@inria.fr>:
On Feb 16, 2013, at 1:57 PM, Ben Coman <btc@openInWorld.com> wrote:
Marcus Denker wrote:
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me. => run everything in headless mode => use the zeroconf scripts
ZeroConf runs already in another place. It is nice! 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
Still, when doing a cmake . and make in the build/ folder, I do get a CogVM.app in results. Shouldn't I get a Pharo.app? Where is this occuring? Phil 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
And inside the app, there is a CogVM executable, not a pharo one. Confused I am. Phil 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
You use the wrong configuration in VMMaker (thanks to the strange naming conventions this happens way too easily) :/ I think you can just use Pharo.*Config instead of Cog.*Config? On 2013-02-16, at 15:18, "phil@highoctane.be" <phil@highoctane.be> wrote:
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am.
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
All right, this wasn't in the workspace being initialized with the .st file in the image folder. Code is generated, cmake works, but make fails. vmVersionInfo.h appears to be missing. Was there when doing the Cog thing. I'll dig. Phil 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
You use the wrong configuration in VMMaker (thanks to the strange naming conventions this happens way too easily) :/
I think you can just use Pharo.*Config instead of Cog.*Config?
On 2013-02-16, at 15:18, "phil@highoctane.be" <phil@highoctane.be> wrote:
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am.
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
Forget that, that file is the only one which is *already* in the build/ folder from the cog.tar, which I trashed when restarting the procedure. One more gotcha... Phil 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
You use the wrong configuration in VMMaker (thanks to the strange naming conventions this happens way too easily) :/
I think you can just use Pharo.*Config instead of Cog.*Config?
On 2013-02-16, at 15:18, "phil@highoctane.be" <phil@highoctane.be> wrote:
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am.
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
Pharo VM built successfully from cog.tar and VMMaker-image now. Now, is there anything like a *Pharo* VM for IOS? Doesn't seem to be any configuration in there. Phil 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
You use the wrong configuration in VMMaker (thanks to the strange naming conventions this happens way too easily) :/
I think you can just use Pharo.*Config instead of Cog.*Config?
On 2013-02-16, at 15:18, "phil@highoctane.be" <phil@highoctane.be> wrote:
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am.
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
On 16 February 2013 17:24, phil@highoctane.be <phil@highoctane.be> wrote:
Pharo VM built successfully from cog.tar and VMMaker-image now.
Thanks for testing , Phil.
Now, is there anything like a *Pharo* VM for IOS? Doesn't seem to be any configuration in there.
There is, but it don't called 'pharo' yet :)
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
You use the wrong configuration in VMMaker (thanks to the strange naming conventions this happens way too easily) :/
I think you can just use Pharo.*Config instead of Cog.*Config?
On 2013-02-16, at 15:18, "phil@highoctane.be" <phil@highoctane.be> wrote:
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am.
Phil
2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:30, "phil@highoctane.be" <phil@highoctane.be> wrote:
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?
yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me.
=> run everything in headless mode => use the zeroconf scripts
-- Best regards, Igor Stasenko.
I was looking in the image/ folder with the newImage.sh script as I wanted to understand what was happening in there. So, this requires something like $PHAROVM to exist and be set to something proper (added to my .profile) Then, there is still ci.lille... in there, to be removed. Next, I wanted to make sense of the script itself. I commented out the part where the pregenerated image got downloaded as I wanted to see things work from zero and not merely a prebuilt image. So, I commented out the prebuilt part. # ---------------------------------------------------------------------------- # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR # echo " $PREBUILT_IMAGE_URL" # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ # unzip image.zip && \ # rm image.zip && \ # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 And then, I got: [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image philippeback$] ./newImage.sh FETCHING FRESH IMAGE https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo... --2013-02-16 14:10:11-- https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo... Which failed. The right URL is: URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/a..." Also, it seems that the original contents of PharoVM do not contain the .sources, and this generates a UI message one has to click, which is annoying. Phil 2013/2/16 Ben Coman <btc@openinworld.com>:
Marcus Denker wrote:
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <estebanlm@gmail.com> 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.
-> only when this is green the zip is updated in the archive
On 2013-02-16, at 14:25, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was looking in the image/ folder with the newImage.sh script as I wanted to understand what was happening in there.
So, this requires something like $PHAROVM to exist and be set to something proper (added to my .profile) Then, there is still ci.lille... in there, to be removed.
Next, I wanted to make sense of the script itself.
I commented out the part where the pregenerated image got downloaded as I wanted to see things work from zero and not merely a prebuilt image.
So, I commented out the prebuilt part.
# ---------------------------------------------------------------------------- # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR # echo " $PREBUILT_IMAGE_URL"
# wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ # unzip image.zip && \ # rm image.zip && \ # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1
And then, I got:
[PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image philippeback$] ./newImage.sh FETCHING FRESH IMAGE https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo... --2013-02-16 14:10:11-- https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo...
Which failed.
The right URL is: URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/a..."
Also, it seems that the original contents of PharoVM do not contain the .sources, and this generates a UI message one has to click, which is annoying.
=> use the urls from our file server and the new build scripts I didn't forgot to update the descriptions since we were out of builds for a while: #get a vm: wget http://files.pharo.org/script/ciPharoVM.sh bash ciPharoVM.sh #get an image: wget http://files.pharo.org/script/ciPharo14.sh bash ciPharo14.sh => to see what the scripts do run bash ciPharoVM.sh --help bash ciPharo14 --help => to run an image headlessly do ./vm.sh Pharo.image => you'll find a complete lists of images under http://files.pharo.org/image/14 I hope that helps?
sure does. 2013/2/16 Camillo Bruni <camillobruni@gmail.com>:
On 2013-02-16, at 14:25, "phil@highoctane.be" <phil@highoctane.be> wrote:
I was looking in the image/ folder with the newImage.sh script as I wanted to understand what was happening in there.
So, this requires something like $PHAROVM to exist and be set to something proper (added to my .profile) Then, there is still ci.lille... in there, to be removed.
Next, I wanted to make sense of the script itself.
I commented out the part where the pregenerated image got downloaded as I wanted to see things work from zero and not merely a prebuilt image.
So, I commented out the prebuilt part.
# ---------------------------------------------------------------------------- # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR # echo " $PREBUILT_IMAGE_URL"
# wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ # unzip image.zip && \ # rm image.zip && \ # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1
And then, I got:
[PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image philippeback$] ./newImage.sh FETCHING FRESH IMAGE https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo... --2013-02-16 14:10:11-- https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo...
Which failed.
The right URL is: URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/a..."
Also, it seems that the original contents of PharoVM do not contain the .sources, and this generates a UI message one has to click, which is annoying.
=> use the urls from our file server and the new build scripts
I didn't forgot to update the descriptions since we were out of builds for a while:
#get a vm:
wget http://files.pharo.org/script/ciPharoVM.sh bash ciPharoVM.sh
#get an image:
wget http://files.pharo.org/script/ciPharo14.sh bash ciPharo14.sh
=> to see what the scripts do run bash ciPharoVM.sh --help bash ciPharo14 --help
=> to run an image headlessly do
./vm.sh Pharo.image
=> you'll find a complete lists of images under http://files.pharo.org/image/14
I hope that helps?
participants (7)
-
Ben Coman -
Camillo Bruni -
Esteban Lorenzano -
Igor Stasenko -
Marcus Denker -
phil＠highoctane.be -
stephane ducasse