Simple plugin for Jenkins to run Pharo/Squeak VM images

I don't know if there will be any use for this, but I had couple of
free hours last weekend and I made simple plugin to run Squeak/Pharo
images inside Jenkins CI-server (formerly Hudson).

After installation one should be able to configure Squeak/Pharo VM
under hudson management. After that one
is able add build step that runs Pharo/Squeak image. One can define
parameters, image and script that is
passed to the given image. I will improve documentation and such when
I have time. However
I will do it faster if there is some interest towars this kind of plugin.

Codes can be loaded form the github. (mvn package should compile
plugin under target dir).
https://github.com/pnuz3n/Jenkins-Pharo-Plugin

There is precompiled version currently available at URL.
http://users.jyu.fi/~pajumasu/jenkins-pharo-plugin/jenkins-pharo-plugin.hpi

--
Panu

thanks panu

did you see that we are heavily using hudson?
Is your code different?

Stef

On Feb 28, 2011, at 3:27 PM, Panu Suominen wrote:

On Feb 28, 2011, at 3:49 PM, Stéphane Ducasse wrote:

> thanks panu
>
> did you see that we are heavily using hudson?
> Is your code different?
>
We are actually not using a plugin but just call shell scripts on the server.
(we use Lukas' scripts https://github.com/renggli/builder )

I know that Philippe did a plugin, too. I always wanted to look at how a plugin can even
simplify the setup... (especially for simple cases), but this has been pushed down the
TODO list...

        Marcus



--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

2011/2/28 Marcus Denker <[hidden email]>:
> We are actually not using a plugin but just call shell scripts on the server.
> (we use Lukas' scripts https://github.com/renggli/builder )
> I know that Philippe did a plugin, too. I always wanted to look at how a plugin can even
> simplify the setup... (especially for simple cases), but this has been pushed down the
> TODO list...

Yep. This is plugin not a shell script. This is the main difference.
Of course the plugin is not so mature
as the shell script. For example I haven't had time to test how to
maintain package cache, but that should
be quite easy to do using Jenkin's workspace.

At my work we have some problems creating new build configurations
using the shell approach and thus we needed plugin to help the
process. Unfortunately I did not find plugin for the job so I had to
start writing one.

--
Panu

On Feb 28, 2011, at 4:03 PM, Panu Suominen wrote:

This start of the sentence I like a lot! :-)

> we have some problems creating new build configurations
> using the shell approach and thus we needed plugin to help the
> process. Unfortunately I did not find plugin for the job so I had to
> start writing one.


I will definitly have a look.

I will send you the plugin (and contact) of Phillippe.

        Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Hi Panu,

I would be interested in this, but I would need help to install it :). I would like to give it a try in the context of Moose.

Is the solution already able to react when errors appear in the image? For example, the shell script solution of Lukas looks for Debug.log and then suspends the process if one appears.

Cheers,
Doru



On 28 Feb 2011, at 16:03, Panu Suominen wrote:

--
www.tudorgirba.com

"Value is always contextual."

2011/2/28 Tudor Girba <[hidden email]>:
> I would be interested in this, but I would need help to install it :). I would like to give it a try in the context of Moose.

On the hudson management there is plugin section there one should be
able to load plugins by uploading files. Other approach is to copy the
plugin to the hudson plugin directory. This is mostly .hudson/plugins
at the home directory of the user running the servlet container hudson
resides in.
More about installing plugins http://wiki.hudson-ci.org/display/HUDSON/Plugins.

> Is the solution already able to react when errors appear in the image? For example, the shell script solution of Lukas looks for Debug.log and then suspends the process if one appears.

No. But I can easily implement the file checking. The "problem" is
that Philippe Marschall has apparently done similar plugin. I don't
know if it wise for this small community to develop two similar
plugins... I have to check what are Phillippe's plans. My idea was to
develop plugin that asks information about ConfigurationOfXXX and
desired version and could do building, testing and reporting based on
that information.

--
Panu

2011/2/28 Panu Suominen <[hidden email]>:
> 2011/2/28 Tudor Girba <[hidden email]>:
>> I would be interested in this, but I would need help to install it :). I would like to give it a try in the context of Moose.
> The "problem" is
> that Philippe Marschall has apparently done similar plugin.

I contacted Philippe and their plugin resides in [1] and some
documentation at [2].
Because it is more mature than the plugin I made, I suggest to use it
instead of mine.
At least I will. :)

1. https://seaside.googlecode.com/svn/trunk/pharo-build
2. http://code.google.com/p/seaside/wiki/PharoBuild

--
Panu

Thanks Panu for investing the time to compare with what Philippe has done.

And thanks Philippe for doing the more mature plugin :)

Cheers,
Doru


On 7 Mar 2011, at 09:02, Panu Suominen wrote:

--
www.tudorgirba.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

Is it published in a git somewhere?

Stef

On Mar 7, 2011, at 9:02 AM, Panu Suominen wrote:

2011/3/7 Stéphane Ducasse <[hidden email]>:
> Is it published in a git somewhere?
Mine is, but there is no point continuing the development of it...

I would also like if the plugin would reside in some git repository. I
cced this mail to Philippe so,
he can answer how this would fit their plans. Their plugin is under
MIT-license so it
is possible for anyone to grab it and put git repository, but I think
more organized approach
would be better. :)