Re: ProjectWonder Jenkins plugin features
Re: ProjectWonder Jenkins plugin features
- Subject: Re: ProjectWonder Jenkins plugin features
- From: Pascal Robert <email@hidden>
- Date: Sun, 26 Aug 2012 21:23:12 -0400
Le 2012-08-26 à 17:43, Ray Kiddy <email@hidden> a écrit :
>
> On Aug 26, 2012, at 5:28 AM, Pascal Robert wrote:
>
>> Hi everyone,
>>
>> Now that the REST and SSH parts have been added into wotaskd, I was wondering what people are expecting to have in a "Project Wonder" plugin for Jenkins.
>>
>> This is what I'm thinking it should have:
>>
>> - The project templates that Dave A. did should be bundled in the plugin, so that you don't need to fetch them, and bonus when you create a new job, the projects type will be listed.
>>
>
> Is good. I do not think have needed to use a plugin. We just had created a job for building our apps a while back and we copy that. But if people like this, it is fine to include.
I must say it's the part of the plugin I'm not sure it's a necessity. The current way to getting the templates from WOJenkins is quite easy, but putting them in the plugin will make it easier (but harder for the plugin writer, that's… me).
>
>> - woproject.jar would be bundled with the plugin.
>>
>
> Is good.
>
>> - For deployment, the plugin will allow people to specify at least wotaskd installations, the password, the path to install the app and the path to install the WSR.
>
> If we could use jenkins to install built apps to our 25+ deployed instance machines, it would be beyond wonderful.
Only gotcha would be that you will need to add 25 wotaskd details into the config, unless we add the SSH/sym link support into JavaMonitor.
> At some point, we will become concerned about the clutter in these directories. I would suggest a "keep x of the last non-deployed versions and y of the last deployed versions" flag, settable per host. Someone will have to go and delete those older versions. It would make sense for jenkins to do it here.
Yeah, didn't think of that.
>> - The plugin could do two types of restart when the app is installed: restart or bounce.
>>
>
> Is also good.
>
>> - It will use the "symlink" type of deployment, meaning that the app will have a unique identifier (MyApp.woa-201208260800) and the plugin will change a symbolic link (MyApp.woa) to point to the new release (MyApp.woa-201208260800). You can define the unique identifier, but if none is specified, it will be a timestamp.
>
> Are you all assuming that the MyApp.woa-201208260800 directory is in the /L/W/Applications directory? We have created a /L/W/Distributions directory and the /L/W/Applications contains only simlinks into that. This seems, somehow, cleaner.
>
> We use the subversion version number in the app name, also. Presumably, we would specify that in the same way we do now.
Yes, in fact that's a task people can add before the plugin does the deployment.
> Actually, we now use a shell-script build phase, and that is kludgey, so, we can hope for better?
>
> If you are pulling from git, would you use the guid of the version? Is anyone else just completely shocked that you cannot go to github.com and search for a guid and just find the exact version of the correct repository? I mean, one would hope that they realize what the "u" in guid means. Duh!
>
>> Opinions?
>
> +1, definitely.
>
> - ray
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden