[Pharo-project] [ANN] Hudson continuous integration server support
I've created a project at: http://www.squeaksource.com/HudsonBuild.html You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests. The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello. The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below. -- Yanni Chiu ========= howto.txt ========= ====== PART A - Prepare image and adjust build scripts ====== Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using: <code> Utilities updateFromServer. [ Gofer gofer load ] on: Error do: [ :err | err retry ]. Gofer gofer recompile. </code> - this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core" Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: SQUEAK_VM IMAGES_HOME SCRIPTS_HOME - you may have to adjust the repository locations too These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases. ====== PART B - Integrate with Hudson ====== Download hudson.war from http://hudson-ci.org/ Start the Hudson server. - run something like: WARFILE=$HOME/apps/hudson/hudson.war LOGFILE=hudson.log nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090 Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save"). Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link ===== HINTS ===== 1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out. 2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong. 3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace. 4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook. 5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough).
thanks this is good idea. Please continue to push it. Stef On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote:
I've created a project at:
http://www.squeaksource.com/HudsonBuild.html
You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests.
The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello.
The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below.
-- Yanni Chiu
========= howto.txt =========
====== PART A - Prepare image and adjust build scripts ======
Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory
Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using:
<code> Utilities updateFromServer. [ Gofer gofer load ] on: Error do: [ :err | err retry ]. Gofer gofer recompile. </code>
- this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core"
Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: SQUEAK_VM IMAGES_HOME SCRIPTS_HOME - you may have to adjust the repository locations too
These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases.
====== PART B - Integrate with Hudson ======
Download hudson.war from http://hudson-ci.org/
Start the Hudson server. - run something like: WARFILE=$HOME/apps/hudson/hudson.war LOGFILE=hudson.log nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090
Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK
Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save").
Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link
===== HINTS =====
1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out.
2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong.
3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace.
4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook.
5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). <Core.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
H Yanni Thank you for the excellent instructions and for sharing this information. I never thought of using Hudson to build Smalltalk images before. Within a few hours I managed to convince Hudson to build some Smalltalk images and run the tests. The setup is pretty ugly (especially the dependencies), but it works reasonably well and the result is as if I would build the images manually (I use the same Gofer scripts) every night: http://hudson.lukas-renggli.ch Thank you! Lukas 2010/1/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
thanks this is good idea. Please continue to push it.
Stef
On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote:
I've created a project at:
  http://www.squeaksource.com/HudsonBuild.html
You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests.
The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello.
The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below.
-- Yanni Chiu
========= howto.txt =========
====== PART A - Prepare image and adjust build scripts ======
Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory
Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using:
<code> Utilities updateFromServer. [ Gofer gofer load ]     on: Error     do: [ :err | err retry ]. Gofer gofer recompile. </code>
- this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core"
Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: Â Â SQUEAK_VM Â Â IMAGES_HOME Â Â SCRIPTS_HOME - you may have to adjust the repository locations too
These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases.
====== PART B - Integrate with Hudson ======
Download hudson.war from http://hudson-ci.org/
Start the Hudson server. - run something like:   WARFILE=$HOME/apps/hudson/hudson.war   LOGFILE=hudson.log   nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090
Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK
Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save").
Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link
===== HINTS =====
1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out.
2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong.
3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace.
4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook.
5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). <Core.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas this is cool. the dependencies you mean the JRE dependencies? I am looking to do the install soon. cheers, Mike On Fri, Jan 8, 2010 at 6:19 AM, Lukas Renggli <renggli@gmail.com> wrote:
H Yanni
Thank you for the excellent instructions and for sharing this information. I never thought of using Hudson to build Smalltalk images before. Within a few hours I managed to convince Hudson to build some Smalltalk images and run the tests. The setup is pretty ugly (especially the dependencies), but it works reasonably well and the result is as if I would build the images manually (I use the same Gofer scripts) every night:
 http://hudson.lukas-renggli.ch
Thank you!
Lukas
2010/1/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
thanks this is good idea. Please continue to push it.
Stef
On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote:
I've created a project at:
  http://www.squeaksource.com/HudsonBuild.html
You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests.
The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello.
The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below.
-- Yanni Chiu
========= howto.txt =========
====== PART A - Prepare image and adjust build scripts ======
Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory
Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using:
<code> Utilities updateFromServer. [ Gofer gofer load ]     on: Error     do: [ :err | err retry ]. Gofer gofer recompile. </code>
- this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core"
Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: Â Â SQUEAK_VM Â Â IMAGES_HOME Â Â SCRIPTS_HOME - you may have to adjust the repository locations too
These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases.
====== PART B - Integrate with Hudson ======
Download hudson.war from http://hudson-ci.org/
Start the Hudson server. - run something like:   WARFILE=$HOME/apps/hudson/hudson.war   LOGFILE=hudson.log   nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090
Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK
Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save").
Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link
===== HINTS =====
1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out.
2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong.
3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace.
4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook.
5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). <Core.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas this is cool. Â the dependencies you mean the JRE dependencies? I am looking to do the install soon.
No, the dependencies between builds are the problem. In my case the dependencies are as followed: Core - unloads the tests and sets my settings > Development - loads RefactoringBrowser and OmniBrowser > Seaside 2.8 - loads Seaside 2.8, Magritte, Pier > Seaside 3.0 - loads Seaside 3.0 I followed the instructions given here <http://wiki.hudson-ci.org/display/HUDSON/Splitting+a+big+job+into+smaller+jo...>. It is really cumbersome. I have to link the workspace of the depended builds into the workspace of the current build, otherwise I cannot access the previous builds to build something on top. I could do everything in one build (and use Mason for the dependency resolution), but then I'd loose the nice per-build reporting of Hudson. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Jan 7, 2010 at 11:56 PM, Lukas Renggli <renggli@gmail.com> wrote:
I could do everything in one build (and use Mason for the dependency resolution), but then I'd loose the nice per-build reporting of Hudson.
I don't see why... you'd just have to do a build for stage A and then one for B (which also goes through A) and so one. You're doing "unnecessary" work, I suppose, by going through A multiple times, but you're also testing that you have a correct dependency specification in the process.
Julian
I don't see why... you'd just have to do a build for stage A and then one for B (which also goes through A) and so one. You're doing "unnecessary" work, I suppose, by going through A multiple times, but you're also testing that you have a correct dependency specification in the process.
I really don't want to repeat the same build multiple times. Downloading and installing Monticello files is just dead slow. It takes 15 minutes to load all OmniBrowser packages, 20 minutes for the Seaside 3.0 packages, and 26 minutes for Seaside 2.8, Magritte and Pier. It's an old machine, but I don't expect it to work the whole night to build a few images. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
I really don't want to repeat the same build multiple times. Downloading and installing Monticello files is just dead slow.
I find building from a local directory is quite fast. E.g. Gofer new directory: '/public/repo'; "squeaksource: 'KomHttpServer';" package: 'DynamicBindings'; package: 'KomServices'; package: 'KomHttpServer'; load. After a successful build, I copied the package-cache to the local repo directory. This was okay for debugging the build scripts, but doesn't work for building from the latest .mcz's. One idea, I've not tried yet, is to use rsync to pull the latest .mcz's down into the local repo. Then, for .mcz's that have no newer version, nothing has to be downloaded. Now that I think about, if you don't have control of the squeak source repository machine, then you can't do this. Also, to avoid filling up the local disk, some rsync filters would be needed, as well as a cron script to remove all but the latest version. Now it's getting too complicated. Following on that thought was to have Hudson monitor the repositories for new packages, and then kick off a build. I've not yet checked whether Hudson can do this. So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details. -- Yanni
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster. I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back? Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
we could host that using the pharo svn account at inria gforge Stef On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote:
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster.
I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back?
Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Jan 9, 2010 at 4:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
we could host that using the pharo svn account at inria gforge
Stef: would you mind sending me in a private email all the information about Pharo SVN ? I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) Damien's bash scripts to build images and I want to start to version them. Cheers Mariano
Stef
On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote:
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster.
I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back?
Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
mariano this is public on the web site :) on forge page of the pharo project at inria. https://gforge.inria.fr/scm/?group_id=1299 Normal svn svn checkout svn://scm.gforge.inria.fr/svn/pharo svn checkout --username login https://scm.gforge.inria.fr/svn/pharo :) On Jan 9, 2010, at 5:02 PM, Mariano Martinez Peck wrote:
On Sat, Jan 9, 2010 at 4:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: we could host that using the pharo svn account at inria gforge
Stef: would you mind sending me in a private email all the information about Pharo SVN ?
I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) Damien's bash scripts to build images and I want to start to version them.
Cheers
Mariano
Stef
On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote:
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster.
I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back?
Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cool. I commited the bash scripts files to: https://scm.gforge.inria.fr/svn/pharo/BuildImages cheers mariano On Sat, Jan 9, 2010 at 9:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
mariano this is public on the web site :) on forge page of the pharo project at inria. https://gforge.inria.fr/scm/?group_id=1299 Normal svn
svn checkout svn://scm.gforge.inria.fr/svn/pharo svn checkout --username login https://scm.gforge.inria.fr/svn/pharo
:)
On Jan 9, 2010, at 5:02 PM, Mariano Martinez Peck wrote:
On Sat, Jan 9, 2010 at 4:54 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
we could host that using the pharo svn account at inria gforge
Stef: would you mind sending me in a private email all the information about Pharo SVN ?
I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) Damien's bash scripts to build images and I want to start to version them.
Cheers
Mariano
Stef
On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote:
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster.
I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back?
Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
can add a page on the wiki to mention it. Stef On Jan 9, 2010, at 10:04 PM, Mariano Martinez Peck wrote:
Cool. I commited the bash scripts files to:
https://scm.gforge.inria.fr/svn/pharo/BuildImages
cheers
mariano
On Sat, Jan 9, 2010 at 9:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: mariano this is public on the web site :) on forge page of the pharo project at inria. https://gforge.inria.fr/scm/?group_id=1299 Normal svn
svn checkout svn://scm.gforge.inria.fr/svn/pharo svn checkout --username login https://scm.gforge.inria.fr/svn/pharo
:)
On Jan 9, 2010, at 5:02 PM, Mariano Martinez Peck wrote:
On Sat, Jan 9, 2010 at 4:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: we could host that using the pharo svn account at inria gforge
Stef: would you mind sending me in a private email all the information about Pharo SVN ?
I refactor (support for Mac OS, cleanup squeak stuff and old stuff ) Damien's bash scripts to build images and I want to start to version them.
Cheers
Mariano
Stef
On Jan 9, 2010, at 3:31 PM, Lukas Renggli wrote:
So here's a new idea. Keep the package-cache from the previous build, and make sure the build image can make use of it -- I'm not sure of the Gofer/Monticello details.
Yeah, Gofer would benefit from the package cache. As far as I know Hudson however cleans the workspace with every new build. I don't know how the package cache could be saved over.
I do keep a global package-cache now, we'll see tomorrow if the builds are faster.
I've departed quite a bit from the scripts of Yanni. I generalize everything into a single script that can then be parametrized from Hudson. I have everything in a private Git repository. How can I contribute it back?
Lukas
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Jan 9, 2010 at 4:31 PM, Lukas Renggli wrote:
I have everything in a private Git repository. How can I contribute it back?
The obvious answer for Git is of course to create yourself a http://github.com account. You'll be able to push your private repository straight there. -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
2010/1/9 Danie Roux <lists+pharo@danieroux.com>:
On Sat, Jan 9, 2010 at 4:31 PM, Lukas Renggli wrote:
I have everything in a private Git repository. How can I contribute it back?
The obvious answer for Git is of course to create yourself a http://github.com account. You'll be able to push your private repository straight there.
Ok, grab it with: git clone git://github.com/renggli/builder.git Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Sat, Jan 9, 2010 at 7:09 PM, Lukas Renggli wrote:
Ok, grab it with:
 git clone git://github.com/renggli/builder.git
Awesome, thanks! For those new to github, this is the entry point, with a rendered README: http://github.com/renggli/builder -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
Lukas Renggli wrote:
2010/1/9 Danie Roux <lists+pharo@danieroux.com>:
On Sat, Jan 9, 2010 at 4:31 PM, Lukas Renggli wrote:
I have everything in a private Git repository. How can I contribute it back? The obvious answer for Git is of course to create yourself a http://github.com account. You'll be able to push your private repository straight there.
Ok, grab it with:
git clone git://github.com/renggli/builder.git
I've updated the project description for the Hudson Build project on squeaksource.com to point at this git repository, for the scripts. Also, I've added you as a developer. Anyone else wanting to be added, please ask. The code base is really tiny. The feature I like to see added is to report the time taken to run each test, but that requires support from SUnit. -- Yanni
Ok, grab it with:
  git clone git://github.com/renggli/builder.git
I've updated the project description for the Hudson Build project on squeaksource.com to point at this git repository, for the scripts. Also, I've added you as a developer. Anyone else wanting to be added, please ask. The code base is really tiny. The feature I like to see added is to report the time taken to run each test, but that requires support from SUnit.
Hi Yanni Thank you for adding me to the repository. I will commit my changes to the HudsonBuildTools there, if this is ok with you? I've made some significant changes: - added methods to run all tests of a package - make the distinction between error and failure - measure the time it took to run a test - display the exception and stack trace of a failing test - encode all XML values properly (I had some problems with the stacks) You can see some failing tests here: http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testReport... I couldn't really find any documentation on this JUnit XML thing, I just filled the empty parts in your code. Lukas I couldn't commit my changes to the HudsonBuildTools, because I had no write rights. I've uploaded the changed runner now.
-- Yanni
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
did one of you had a look at the enh proposed by adrian K because they looks interesting. I got no time to go the next step (removing the loading error). Stef On Jan 10, 2010, at 9:49 AM, Lukas Renggli wrote:
Ok, grab it with:
git clone git://github.com/renggli/builder.git
I've updated the project description for the Hudson Build project on squeaksource.com to point at this git repository, for the scripts. Also, I've added you as a developer. Anyone else wanting to be added, please ask. The code base is really tiny. The feature I like to see added is to report the time taken to run each test, but that requires support from SUnit.
Hi Yanni
Thank you for adding me to the repository. I will commit my changes to the HudsonBuildTools there, if this is ok with you?
I've made some significant changes:
- added methods to run all tests of a package - make the distinction between error and failure - measure the time it took to run a test - display the exception and stack trace of a failing test - encode all XML values properly (I had some problems with the stacks)
You can see some failing tests here:
http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testReport...
I couldn't really find any documentation on this JUnit XML thing, I just filled the empty parts in your code.
Lukas
I couldn't commit my changes to the HudsonBuildTools, because I had no write rights. I've uploaded the changed runner now.
-- Yanni
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas Renggli wrote:
Thank you for adding me to the repository. I will commit my changes to the HudsonBuildTools there, if this is ok with you?
I've made some significant changes:
- added methods to run all tests of a package - make the distinction between error and failure - measure the time it took to run a test - display the exception and stack trace of a failing test - encode all XML values properly (I had some problems with the stacks)
Wow this is great. You guys work so fast, I can't keep up. -- Yanni
Lukas is impressive. You would see it coding new parser in helvetia :) or helping to port Moose VisualWorks into pharo. It was cool. Stef On Jan 10, 2010, at 7:48 PM, Yanni Chiu wrote:
Lukas Renggli wrote:
Thank you for adding me to the repository. I will commit my changes to the HudsonBuildTools there, if this is ok with you?
I've made some significant changes:
- added methods to run all tests of a package - make the distinction between error and failure - measure the time it took to run a test - display the exception and stack trace of a failing test - encode all XML values properly (I had some problems with the stacks)
Wow this is great. You guys work so fast, I can't keep up.
-- Yanni
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
this is getting cool :) Stef On Jan 8, 2010, at 7:19 AM, Lukas Renggli wrote:
H Yanni
Thank you for the excellent instructions and for sharing this information. I never thought of using Hudson to build Smalltalk images before. Within a few hours I managed to convince Hudson to build some Smalltalk images and run the tests. The setup is pretty ugly (especially the dependencies), but it works reasonably well and the result is as if I would build the images manually (I use the same Gofer scripts) every night:
http://hudson.lukas-renggli.ch
Thank you!
Lukas
2010/1/5 Stéphane Ducasse <stephane.ducasse@inria.fr>:
thanks this is good idea. Please continue to push it.
Stef
On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote:
I've created a project at:
http://www.squeaksource.com/HudsonBuild.html
You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests.
The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello.
The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below.
-- Yanni Chiu
========= howto.txt =========
====== PART A - Prepare image and adjust build scripts ======
Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory
Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using:
<code> Utilities updateFromServer. [ Gofer gofer load ] on: Error do: [ :err | err retry ]. Gofer gofer recompile. </code>
- this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core"
Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: SQUEAK_VM IMAGES_HOME SCRIPTS_HOME - you may have to adjust the repository locations too
These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases.
====== PART B - Integrate with Hudson ======
Download hudson.war from http://hudson-ci.org/
Start the Hudson server. - run something like: WARFILE=$HOME/apps/hudson/hudson.war LOGFILE=hudson.log nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090
Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK
Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save").
Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link
===== HINTS =====
1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out.
2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong.
3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace.
4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook.
5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). <Core.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Danie Roux -
Julian Fitzell -
Lukas Renggli -
Mariano Martinez Peck -
Michael Roberts -
Stéphane Ducasse -
Yanni Chiu