Le 2012-08-26 à 17:43, Ray Kiddy <[email protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
