Re: ProjectWonder Jenkins plugin features
Re: ProjectWonder Jenkins plugin features
- Subject: Re: ProjectWonder Jenkins plugin features
- From: David Avendasora <email@hidden>
- Date: Mon, 27 Aug 2012 10:38:07 +0800
Hello all, yes, I'm still alive, Malaysian shanty towns haven't entirely swallowed me.
Yet.
On Aug 27, 2012, at 6:14 AM, Johann Werner wrote:
>
> Am 26.08.2012 um 23:43 schrieb Ray Kiddy <email@hidden>:
>
>>
>> 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.
I would LOVE to see this happen! I've looked at it multiple times, but the Maven requirement always stopped me cold. Learning maven and Jenkins' plugin architecture is just too steep a learning curve for me. It certainly isn't "So easy, even Dave Avendasora can do it.™"
>>> 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.
+ 1. I'd like to keep the job templates and scripts as their own git repository and have them included in the plugin as a git submodule.
>> 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.
A plugin certainly isn't _required_ to use Jenkins to build WO, but it would make life much easier for those that are just getting started and/or don't have unusual build needs. Just like "Fluffy Bunny" isn't the _only_ way to structure a WO project (maven, I'm looking at you), it is the _assumed_ way. Having a Jenkins plugin would make it easier to define a "Fluffy Butler™" build and deployment setup & workflow.
As a matter of fact, I think "Fluffy Butler" is an excellent name for the plugin.
>>
>>> - woproject.jar would be bundled with the plugin.
>>>
>>
>> Is good.
Yes! Maybe splitting the woproject code out of WOLips into it's own repository would be a good idea?
>>> - 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.
>>
>> 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.
I agree with keeping with Jenkins' existing metaphor of keeping previous builds for keeping previous deployments.
>>
>>> - The plugin could do two types of restart when the app is installed: restart or bounce.
>>>
>>
>> Is also good.
Another important feature would be the ability to gracefully deploy by setting an instance to refuse new sessions for, say, 30 minutes, set a property that the app can use to display a message to the user of impeding downtime, then do the restart at the specified time.
Being able to deal with multiple instances of an application running on a single server would be helpful, too, but that's getting beyond the "good for the beginner" scope.
>>> - 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. 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!
I think for the initial release we could get by with a simple timestamp. I like the idea of being able to customize the directory name and location using build/repository info, but I think the key is that the plugin will be most useful for the person getting started. Once you need more capability, if the plugin doesn't offer it, you can always go straight Jenkins with your own scripts.
> Instead of using the timestamp or subversion/git artifact just use the build number provided by Jenkins. It is available as environment variable BUILD_NUMBER.
>
>>> Opinions?
>>
>> +1, definitely.
>>
>> - ray
+1
Dave
_______________________________________________
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