[Pharo-project] Interim build server
Hi, following on from the timely Hudson post ;-) I too have been working on continuous integration. I am more interested in identifying & integrating the various bits of plumbing first rather than the build solution itself. I figured the infrastructure needed to be understood first, and there could be value in such an interim solution To this end I have: -written a simple image builder that updates the image in place. -running remotely on a Linux host I have borrowed access -building PharoCore 1.1 from #11110 onwards -started to publish images at http://pharo.gforge.inria.fr/experimental/ remaining is to rename the core images to unstable and then look at running some tests. This has exposed various issues, mainly image timeout caused by the various dialogs that can popup when filing in code. so 1) if anyone would like to test the integrity of these experimental auto-build images, please do 2) discuss if something in this namespace http://pharo.gforge.inria.fr/<> is suitable for automatic publishing - i am not sure how you automatically create gforge "releases" but for core images perhaps this is not needed 3) find a real server we can run this on, (if this is considered worthwhile). My requirements are Linux + daemontools + vnc server - i can host my solution for a while, we need something strategic then once we have a server I'm happy to look at Hudson or whatever we consider the right tool for doing this. I have also been playing with Mason and sent some feedback to Colin. Like i say, for me the real issues are running a Pharo image completely automated. Cheers, Mike
Michael Roberts wrote:
... then once we have a server I'm happy to look at Hudson or whatever we consider the right tool for doing this. I have also been playing with Mason and sent some feedback to Colin. Like i say, for me the real issues are running a Pharo image completely automated.
I think one important issue is running the tests and making the results easily visible. Hudson can be configured to send emails (to an appropriate recipient) if a build fails. Building and running tests is not being done frequently enough so that the feedback can be acted on quickly (when it's most effective). I'm hoping that the Hudson stuff can do that. I don't have a server available to set it up currently, but maybe shortly. -- Yanni
mike I will ask in my team if our infrastructure can be used. Damien, marcus do you know the servers we have? Stef On Jan 5, 2010, at 10:27 PM, Michael Roberts wrote:
Hi, following on from the timely Hudson post ;-) I too have been working on continuous integration. I am more interested in identifying & integrating the various bits of plumbing first rather than the build solution itself. I figured the infrastructure needed to be understood first, and there could be value in such an interim solution
To this end I have: -written a simple image builder that updates the image in place. -running remotely on a Linux host I have borrowed access -building PharoCore 1.1 from #11110 onwards -started to publish images at http://pharo.gforge.inria.fr/experimental/
remaining is to rename the core images to unstable and then look at running some tests. This has exposed various issues, mainly image timeout caused by the various dialogs that can popup when filing in code.
so 1) if anyone would like to test the integrity of these experimental auto-build images, please do 2) discuss if something in this namespace http://pharo.gforge.inria.fr/<> is suitable for automatic publishing - i am not sure how you automatically create gforge "releases" but for core images perhaps this is not needed 3) find a real server we can run this on, (if this is considered worthwhile). My requirements are Linux + daemontools + vnc server - i can host my solution for a while, we need something strategic
then once we have a server I'm happy to look at Hudson or whatever we consider the right tool for doing this. I have also been playing with Mason and sent some feedback to Colin. Like i say, for me the real issues are running a Pharo image completely automated.
Cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 6, 2010, at 8:08 AM, Stéphane Ducasse wrote:
mike
I will ask in my team if our infrastructure can be used. Damien, marcus do you know the servers we have?
I will check with Damien. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
stef: great. Yanni: I agree. I used to run the tests myself and publish them to the google wiki for the end of 1.0 cycle. it did not scale ;-) I see the two efforts as complimentary. I am really working from the inside out. Your approach is outside in. For example I have refactored the image update code so that it is a bit more manageable. Detecting the build failures is important, for example as I wrote my post, an update stalled with EOCD error in MC code. hudson looks good. all the dashboard and easy install stuff for free. do you regularly use & maintain it? cheers, Mike On Wed, Jan 6, 2010 at 7:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mike
I will ask in my team if our infrastructure can be used. Damien, marcus do you know the servers we have?
Stef
On Jan 5, 2010, at 10:27 PM, Michael Roberts wrote:
Hi, following on from the timely Hudson post ;-) I too have been working on continuous integration. I am more interested in identifying & integrating the various bits of plumbing first rather than the build solution itself. Â I figured the infrastructure needed to be understood first, and there could be value in such an interim solution
To this end I have: -written a simple image builder that updates the image in place. -running remotely on a Linux host I have borrowed access -building PharoCore 1.1 from #11110 onwards -started to publish images at http://pharo.gforge.inria.fr/experimental/
remaining is to rename the core images to unstable and then look at running some tests. Â This has exposed various issues, mainly image timeout caused by the various dialogs that can popup when filing in code.
so 1) if anyone would like to test the integrity of these experimental auto-build images, please do 2) discuss if something in this namespace http://pharo.gforge.inria.fr/<> is suitable for automatic publishing  - i am not sure how you automatically create gforge "releases" but for core images perhaps this is not needed 3) find a real server we can run this on, (if this is considered worthwhile). My requirements are Linux + daemontools + vnc server  - i can host my solution for a while, we need something strategic
then once we have a server I'm happy to look at Hudson or whatever we consider the right tool for doing this. Â I have also been playing with Mason and sent some feedback to Colin. Â Like i say, for me the real issues are running a Pharo image completely automated.
Cheers, Mike
_______________________________________________ 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 Jan 6, 2010, at 9:29 AM, Michael Roberts wrote:
stef: great. Yanni: I agree. I used to run the tests myself and publish them to the google wiki for the end of 1.0 cycle. it did not scale ;-)
I see the two efforts as complimentary. I am really working from the inside out. Your approach is outside in. For example I have refactored the image update code so that it is a bit more manageable. Detecting the build failures is important, for example as I wrote my post, an update stalled with EOCD error in MC code.
this is cool!
hudson looks good. all the dashboard and easy install stuff for free. do you regularly use & maintain it?
cheers, Mike
On Wed, Jan 6, 2010 at 7:08 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
mike
I will ask in my team if our infrastructure can be used. Damien, marcus do you know the servers we have?
Stef
On Jan 5, 2010, at 10:27 PM, Michael Roberts wrote:
Hi, following on from the timely Hudson post ;-) I too have been working on continuous integration. I am more interested in identifying & integrating the various bits of plumbing first rather than the build solution itself. I figured the infrastructure needed to be understood first, and there could be value in such an interim solution
To this end I have: -written a simple image builder that updates the image in place. -running remotely on a Linux host I have borrowed access -building PharoCore 1.1 from #11110 onwards -started to publish images at http://pharo.gforge.inria.fr/experimental/
remaining is to rename the core images to unstable and then look at running some tests. This has exposed various issues, mainly image timeout caused by the various dialogs that can popup when filing in code.
so 1) if anyone would like to test the integrity of these experimental auto-build images, please do 2) discuss if something in this namespace http://pharo.gforge.inria.fr/<> is suitable for automatic publishing - i am not sure how you automatically create gforge "releases" but for core images perhaps this is not needed 3) find a real server we can run this on, (if this is considered worthwhile). My requirements are Linux + daemontools + vnc server - i can host my solution for a while, we need something strategic
then once we have a server I'm happy to look at Hudson or whatever we consider the right tool for doing this. I have also been playing with Mason and sent some feedback to Colin. Like i say, for me the real issues are running a Pharo image completely automated.
Cheers, Mike
_______________________________________________ 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
Michael Roberts wrote:
... hudson looks good. all the dashboard and easy install stuff for free. do you regularly use & maintain it?
I don't know anything about the community around Hudson. I happened to see it at: http://ese.unibe.ch/exercises/project-cycle-1/ci (which supported Lukas' software engineering course). I liked the features of Hudson, but didn't know how it could help with Smalltalk. Then I fell victim to the infamous "Save & quit" disaster, and lost my trusty image. I knew I was not building from scratch frequently enough, because I found the process long and tedious. After too much time spent on Metacello, and other meanderings, the net results are the build scripts and SUnit-to-Hudson test report XML code that was released. I use it regularly now. I use a day to day work image. When something is stable, I save the Monticello packages, then go to my Hudson webpage and click "Build now". When I feel the need to refresh my day to day work image, then I navigate to the images directory in the job's workspace, and click on "(all files in zip)" to download the newly built and tested images. BTW, the test cases seem to run about ten times faster when built in a headless image. One set of test cases took about 15 minutes to run from the TestRunner GUI, but the automated build & test took just a minute and a half. Another thing - Hudson has RSS feeds for the builds, so no need to email anyone. Those interested should just subscribe to the feed. -- Yanni
Michael Roberts wrote:
... hudson looks good. all the dashboard and easy install stuff for free. do you regularly use & maintain it?
I don't know anything about the community around Hudson. I happened to see it at:
http://ese.unibe.ch/exercises/project-cycle-1/ci
(which supported Lukas' software engineering course). I liked the features of Hudson, but didn't know how it could help with Smalltalk.
Then I fell victim to the infamous "Save & quit" disaster, and lost my trusty image. I knew I was not building from scratch frequently enough, because I found the process long and tedious. After too much time spent on Metacello, and other meanderings, the net results are the build scripts and SUnit-to-Hudson test report XML code that was released.
I use it regularly now. I use a day to day work image. When something is stable, I save the Monticello packages, then go to my Hudson webpage and click "Build now". When I feel the need to refresh my day to day work image, then I navigate to the images directory in the job's workspace, and click on "(all files in zip)" to download the newly built and tested images.
BTW, the test cases seem to run about ten times faster when built in a headless image. One set of test cases took about 15 minutes to run from the TestRunner GUI, but the automated build & test took just a minute and a half.
interesting. A notification resulting in UI update... or something like that.
Another thing - Hudson has RSS feeds for the builds, so no need to email anyone. Those interested should just subscribe to the feed.
-- Yanni
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Jan 5, 2010 at 10:27 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
-started to publish images at http://pharo.gforge.inria.fr/experimental/
take care that INRIA GForge admins don't like too much stuffs in the web folders. These folders should only be used to host a website. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
for the moment I would not care. There is no written that say that we cannot use a web folders for putting binary code. On Jan 11, 2010, at 11:30 AM, Damien Cassou wrote:
On Tue, Jan 5, 2010 at 10:27 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
-started to publish images at http://pharo.gforge.inria.fr/experimental/
take care that INRIA GForge admins don't like too much stuffs in the web folders. These folders should only be used to host a website.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Damien Cassou -
Marcus Denker -
Michael Roberts -
Stéphane Ducasse -
Yanni Chiu