[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).
> <Core.zip>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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 <[hidden email]>:
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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 <[hidden email]>:
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> On Sat, Jan 9, 2010 at 4:54 PM, Stéphane Ducasse <[hidden email]> 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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 <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2010/1/9 Danie Roux <[hidden email]>:
>> 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