automated builds in D5Pro
Locked
 
|
Hello,
is there any official way to deploy a package from the command line? Best regards, Maxim Fridental |
Re: automated builds in D5Pro
|
|
Maxim,
> is there any official way to deploy a package from the command line? Not that I know of. You could probably automate the process to some extent, maybe with an image that automatically loads packages and sets options when started. The actual Lagoon deployment might be a bit difficult to drive programmatically, I've never tried, but perhaps that could be done as well? If you know all the options are correct then you could just add some code that, in effect, pressed the deploy button immediately after the wizard dialog opened. -- Ian |
Re: automated builds in D5Pro
|
|
In reply to this post by Maxim Fridental
"Maxim Fridental" <[hidden email]> wrote in message
news:b69p16$32bnn$[hidden email]... > Hello, > > is there any official way to deploy a package from the command line? None that I am aware of. However I think it could be done. Some interesting places to look are DevelopmentSessionManager<<handleOpenArguments. This allows one to open workspaces packages, etc... There are a number of creative ways to trick Dolphin into executing code via a package, but I don't know if it would be a problem to try to start a deployment while it thinks it is loading a package. Perhaps this method could be enhanced to run code. Another place to look is DevelopmentSessionManager<<preStart. That method will look for and if found file in a file called prestart.st. This file might be evaluated too soon to deploy, so you might need to fork a process and wait for the system to finish loading. I think it would be cool if Dolphin supported a way to file in (run) a workspace file from the command line. I think that would make it easy to automate a deployment. Chris |
|
|
Chris,
> I think it would be cool if Dolphin supported a way to file in (run) a > workspace file from the command line. I think that would make it easy to > automate a deployment. Look for prestart.st, or something similar to that. Make sure you put it in the correct directory. If you do enough automation to get Dolphin to start and deploy (SuiteBuilder might help a little), then you might end up needing to delete the pre start file in order to get Dolphin to run normally again. Another option might be to have the "real" file under a different name, copy it to the magic name to deploy, and then have the last step in the sequence delete the file to allow Dolphin to run normally. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
|
|
In reply to this post by Christopher J. Demers
Christopher J. Demers wrote:
> "Maxim Fridental" <[hidden email]> wrote in message > news:b69p16$32bnn$[hidden email]... > > Hello, > > > > is there any official way to deploy a package from the command line? > > None that I am aware of. However I think it could be done. Yep. I have proof that it can be done. :-)For those interested, I'll describe what I did. > Some interesting places to look are > DevelopmentSessionManager<<handleOpenArguments. > [snip] > Another place > to look is DevelopmentSessionManager<<preStart. I think I basically took inspiration from both those places. > I think it would be cool if Dolphin supported a way to file in (run) a > workspace file from the command line. I think that would make it easy to > automate a deployment. This is essentially what I ended up putting together. It would be good though if this was a standard part of the base image. I put in a subclass of DevelopmentSessionManager that looks for command line arguments that begin with '-process'. For all that it finds, it takes the rest of the argument as a filename which is then filed-in. <code> DevelopmentSessionManager subclass: #MyDevelopmentSessionManager instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' classInstanceVariableNames: ''! !MyDevelopmentSessionManager methodsFor! handleProcessCommandLineArgs | prefix | prefix := '-process'. self argv do: [:each | (each leftString: prefix size) = prefix ifTrue: [self processArg: (each rightString: each size - prefix size)]]! main super main. self handleProcessCommandLineArgs! processArg: aString SourceManager default fileIn: aString! ! !MyDevelopmentSessionManager class methodsFor! initialize self installNew! ! </code> I start with a pristine image from Object-Arts that has had the Live Update patches applied. After installing the above for MyDevelopmentSessionManager I save it as 'starting.img'. From that point on, everything can be done automatically with batch files and Smalltalk scripts. I have a batch file that starting from that image, builds a fresh working image from source, runs all the unit tests, and if successful, goes on to strip the image, run the ClickTeam install maker, and finally saves the resulting executables and working image in a backup directory with automatically incremented build numbers as part of the filename. Each step of the batch file (except the install maker) involves running the regular Dolphin environment with a Smalltalk script. For instance, the first step is handled by: start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk 5.0\Dolphin.exe" -nosplash Starting.img "-processBuildFreshImage.st" The BuildFreshImage.st file is fairly involved. First it loads the Source Tracking System and some other packages from .pac files. It then loads the bulk of the code from the STS repository. One interesting thing there is that I got tired of managing putting the latest version of all the package editions into a "project". So I have the script do: (self sourceControl getPackageEditionsFor: aPackageName) first load. which always loads the most recent version of a package edition. (I think that makes it something like an open edition in Envy?) The build finishes up by setting various environment preferences and then saving the image as 'fresh.img'. Lastly it does "SessionManager current quit: 0." to exit and return control to the batch file. (Some scripts may also exit with "-1", which the batch file can test in errorlevel). The batch command line that does the image strip is: start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk 5.0\Dolphin.exe" -nosplash Fresh.img "-processStripImage.st" And the contents of "StripImage.st" is: SessionManager inputState queueDeferredAction: (MessageSend receiver: (Package manager packageNamed: 'ST Application UI') imageStripper selector: #stripAndSaveWithProgress) ! I've set up the various options for the image stripper as usual, using the wizard. All of those settings get saved with the package, and get taken care of as part of building the fresh image from source. The one change needed in my subclass of ImageStripper to get it to work in a batch environment was to override #saveExecutable:. I commented out the UserLibrary>>messageBox:lpText:lpCaption:uType: call, which would otherwise interrupt the batch process with a needless prompt. I'll end a typical development session by reviewing the packages that have been marked as changed. Using STS, I'll compare the current package with the latest version in the repository. Sometimes there's no difference, if some experiment was done, or a #halt inserted and then removed. In that case I just clear the change marker. Sometimes looking at the changes reminds me of things to clean up. Eventually, I'll have versioned each of the changed packages. At that point all of the change markers will have been cleared, and all source saved in the most recent package editions. The neat thing is that, should I want to, I'm literally one click away from building a fresh image and executables ready for deployment. Hopefully others will find some useful ideas here. regards, -Bill ------------------------------------------- Bill Dargel [hidden email] Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA |
|
|
"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]... > > Hopefully others will find some useful ideas here. If nothing else, running Dolphin -nosplash means a lot less water on the carpet. |
Re: automated builds in D5Pro
|
|
In reply to this post by Bill Dargel
"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]... > Christopher J. Demers wrote: > > > "Maxim Fridental" <[hidden email]> wrote in message > > news:b69p16$32bnn$[hidden email]... > > > Hello, > > > > > > is there any official way to deploy a package from the command line? > > > > None that I am aware of. However I think it could be done. > > Yep. I have proof that it can be done. :-)For those interested, I'll > what I did. ... Thanks for the details. I think I will use your trick on the next "virgin" image I setup when OA releases the upgrade later this week. I think many of us could benefit if this -process capability were added by OA. I can't really see a downside to it. I currently have a batch file to copy and open a virgin image for deployment. Now I will automate the loading of my package, and the deployment. Thanks, Chris |
Re: automated builds in D5Pro
|
|
In reply to this post by Bill Dargel
Bill Dargel wrote:
> Christopher J. Demers wrote: > > > "Maxim Fridental" <[hidden email]> wrote in message > > news:b69p16$32bnn$[hidden email]... > > > Hello, > > > > > > is there any official way to deploy a package from the command line? > > > > None that I am aware of. However I think it could be done. > > Yep. I have proof that it can be done. :-)For those interested, I'll describe > what I did. > > > Some interesting places to look are > > DevelopmentSessionManager<<handleOpenArguments. > > [snip] > > Another place > > to look is DevelopmentSessionManager<<preStart. > > I think I basically took inspiration from both those places. > > > I think it would be cool if Dolphin supported a way to file in > > workspace file from the command line. I think that would make it easy to > > automate a deployment. > > This is essentially what I ended up putting together. It would be good though if > this was a standard part of the base image. I put in a subclass of > DevelopmentSessionManager that looks for command line arguments that begin with > '-process'. For all that it finds, it takes the rest of the argument as a > filename which is then filed-in. > > <code> > DevelopmentSessionManager subclass: #MyDevelopmentSessionManager > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > classInstanceVariableNames: ''! > > !MyDevelopmentSessionManager methodsFor! > > handleProcessCommandLineArgs > | prefix | > prefix := '-process'. > self argv do: > [:each | > (each leftString: prefix size) = prefix > ifTrue: [self processArg: (each rightString: each size - prefix > > main > super main. > self handleProcessCommandLineArgs! > > processArg: aString > SourceManager default fileIn: aString! ! > > !MyDevelopmentSessionManager class methodsFor! > > initialize > self installNew! ! > > </code> > > I start with a pristine image from Object-Arts that has had the Live > patches applied. After installing the above for MyDevelopmentSessionManager I > save it as 'starting.img'. From that point on, everything can be done > automatically with batch files and Smalltalk scripts. > > I have a batch file that starting from that image, builds a fresh working image > from source, runs all the unit tests, and if successful, goes on to strip the > image, run the ClickTeam install maker, and finally saves the resulting > executables and working image in a backup directory with automatically > incremented build numbers as part of the filename. > > Each step of the batch file (except the install maker) involves running the > regular Dolphin environment with a Smalltalk script. > > For instance, the first step is handled by: > start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk > 5.0\Dolphin.exe" -nosplash Starting.img "-processBuildFreshImage.st" > > The BuildFreshImage.st file is fairly involved. First it loads the Source > Tracking System and some other packages from .pac files. It then loads the bulk > of the code from the STS repository. One interesting thing there is that I got > tired of managing putting the latest version of all the package editions into a > "project". So I have the script do: > (self sourceControl getPackageEditionsFor: aPackageName) first load. > which always loads the most recent version of a package edition. (I think that > makes it something like an open edition in Envy?) > > The build finishes up by setting various environment preferences and then saving > the image as 'fresh.img'. Lastly it does "SessionManager current quit: 0." to > exit and return control to the batch file. (Some scripts may also exit with > "-1", which the batch file can test in errorlevel). > > The batch command line that does the image strip is: > start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk > 5.0\Dolphin.exe" -nosplash Fresh.img "-processStripImage.st" > > And the contents of "StripImage.st" is: > SessionManager inputState > queueDeferredAction: (MessageSend > receiver: (Package manager packageNamed: 'ST Application UI') > selector: #stripAndSaveWithProgress) ! > > I've set up the various options for the image stripper as usual, using the > wizard. All of those settings get saved with the package, and get taken care of > as part of building the fresh image from source. The one change needed in my > subclass of ImageStripper to get it to work in a batch environment was to > override #saveExecutable:. I commented out the > UserLibrary>>messageBox:lpText:lpCaption:uType: call, which would otherwise > interrupt the batch process with a needless prompt. > > I'll end a typical development session by reviewing the packages that have been > marked as changed. Using STS, I'll compare the current package with the latest > version in the repository. Sometimes there's no difference, if some experiment > was done, or a #halt inserted and then removed. In that case I just clear the > change marker. Sometimes looking at the changes reminds me of things to clean > up. Eventually, I'll have versioned each of the changed packages. At that point > all of the change markers will have been cleared, and all source saved in the > most recent package editions. The neat thing is that, should I want to, I'm > literally one click away from building a fresh image and executables ready for > deployment. > > Hopefully others will find some useful ideas here. > > regards, > -Bill > > ------------------------------------------- > Bill Dargel [hidden email] > Shoshana Technologies > 100 West Joy Road, Ann Arbor, MI 48105 USA |
Re: automated builds in D5Pro
|
|
Crap - stupid google, I wrote the post then it didn't even include the
darn thing. Back to thunderbird... I've finally got around to setting up this automated build process, and have a base image with this new runtime manager in it, but the .st files I'm filein don't seem to do anything, my script currently contains: SessionManager current saveImage: 'fresh.img'. SessionManager current quit: 0. Short and sweet, doesn't do anything other than save the base image as a fresh image, or in theory it should, but it doesn't seem to do anything. Is there something simple I'm missing from the filein script to make it actually do something? ( selecting file-in from the menu does the same "nothing" as well... [hidden email] wrote: >Bill Dargel wrote: > > >>Christopher J. Demers wrote: >> >> >> >>>"Maxim Fridental" <[hidden email]> wrote in message >>>news:b69p16$32bnn$[hidden email]... >>> >>> >>>>Hello, >>>> >>>>is there any official way to deploy a package from the command >>>> >>>> >line? > > >>>None that I am aware of. However I think it could be done. >>> >>> >>Yep. I have proof that it can be done. :-)For those interested, I'll >> >> >describe > > >>what I did. >> >> >> >>>Some interesting places to look are >>>DevelopmentSessionManager<<handleOpenArguments. >>>[snip] >>>Another place >>>to look is DevelopmentSessionManager<<preStart. >>> >>> >>I think I basically took inspiration from both those places. >> >> >> >>>I think it would be cool if Dolphin supported a way to file in >>> >>> >(run) a > > >>>workspace file from the command line. I think that would make it >>> >>> >easy to > > >>>automate a deployment. >>> >>> >>This is essentially what I ended up putting together. It would be >> >> >good though if > > >>this was a standard part of the base image. I put in a subclass of >>DevelopmentSessionManager that looks for command line arguments that >> >> >begin with > > >>'-process'. For all that it finds, it takes the rest of the argument >> >> >as a > > >>filename which is then filed-in. >> >><code> >>DevelopmentSessionManager subclass: #MyDevelopmentSessionManager >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> classInstanceVariableNames: ''! >> >>!MyDevelopmentSessionManager methodsFor! >> >>handleProcessCommandLineArgs >> | prefix | >> prefix := '-process'. >> self argv do: >> [:each | >> (each leftString: prefix size) = prefix >> ifTrue: [self processArg: (each rightString: each size - prefix >> >> >size)]]! > > >>main >> super main. >> self handleProcessCommandLineArgs! >> >>processArg: aString >> SourceManager default fileIn: aString! ! >> >>!MyDevelopmentSessionManager class methodsFor! >> >>initialize >> self installNew! ! >> >></code> >> >>I start with a pristine image from Object-Arts that has had the Live >> >> >Update > > >>patches applied. After installing the above for >> >> >MyDevelopmentSessionManager I > > >>save it as 'starting.img'. From that point on, everything can be done >>automatically with batch files and Smalltalk scripts. >> >>I have a batch file that starting from that image, builds a fresh >> >> >working image > > >>from source, runs all the unit tests, and if successful, goes on to >> >> >strip the > > >>image, run the ClickTeam install maker, and finally saves the >> >> >resulting > > >>executables and working image in a backup directory with >> >> >automatically > > >>incremented build numbers as part of the filename. >> >>Each step of the batch file (except the install maker) involves >> >> >running the > > >>regular Dolphin environment with a Smalltalk script. >> >>For instance, the first step is handled by: >>start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk >>5.0\Dolphin.exe" -nosplash Starting.img "-processBuildFreshImage.st" >> >>The BuildFreshImage.st file is fairly involved. First it loads the >> >> >Source > > >>Tracking System and some other packages from .pac files. It then >> >> >loads the bulk > > >>of the code from the STS repository. One interesting thing there is >> >> >that I got > > >>tired of managing putting the latest version of all the package >> >> >editions into a > > >>"project". So I have the script do: >> (self sourceControl getPackageEditionsFor: aPackageName) first >> >> >load. > > >>which always loads the most recent version of a package edition. (I >> >> >think that > > >>makes it something like an open edition in Envy?) >> >>The build finishes up by setting various environment preferences and >> >> >then saving > > >>the image as 'fresh.img'. Lastly it does "SessionManager current >> >> >quit: 0." to > > >>exit and return control to the batch file. (Some scripts may also >> >> >exit with > > >>"-1", which the batch file can test in errorlevel). >> >>The batch command line that does the image strip is: >>start /wait "title" "C:\Program Files\Object Arts\Dolphin Smalltalk >>5.0\Dolphin.exe" -nosplash Fresh.img "-processStripImage.st" >> >>And the contents of "StripImage.st" is: >>SessionManager inputState >> queueDeferredAction: (MessageSend >> receiver: (Package manager packageNamed: 'ST Application UI') >> >> >imageStripper > > >> selector: #stripAndSaveWithProgress) ! >> >>I've set up the various options for the image stripper as usual, >> >> >using the > > >>wizard. All of those settings get saved with the package, and get >> >> >taken care of > > >>as part of building the fresh image from source. The one change >> >> >needed in my > > >>subclass of ImageStripper to get it to work in a batch environment >> >> >was to > > >>override #saveExecutable:. I commented out the >>UserLibrary>>messageBox:lpText:lpCaption:uType: call, which would >> >> >otherwise > > >>interrupt the batch process with a needless prompt. >> >>I'll end a typical development session by reviewing the packages that >> >> >have been > > >>marked as changed. Using STS, I'll compare the current package with >> >> >the latest > > >>version in the repository. Sometimes there's no difference, if some >> >> >experiment > > >>was done, or a #halt inserted and then removed. In that case I just >> >> >clear the > > >>change marker. Sometimes looking at the changes reminds me of things >> >> >to clean > > >>up. Eventually, I'll have versioned each of the changed packages. At >> >> >that point > > >>all of the change markers will have been cleared, and all source >> >> >saved in the > > >>most recent package editions. The neat thing is that, should I want >> >> >to, I'm > > >>literally one click away from building a fresh image and executables >> >> >ready for > > >>deployment. >> >>Hopefully others will find some useful ideas here. >> >>regards, >>-Bill >> >>------------------------------------------- >>Bill Dargel [hidden email] >>Shoshana Technologies >>100 West Joy Road, Ann Arbor, MI 48105 USA >> >> > > > |
Re: automated builds in D5Pro
|
|
Mark Derricutt wrote:
> > SessionManager current saveImage: 'fresh.img'. > SessionManager current quit: 0. *slap thwap fwap* Ok, so what I -didn't- quote here was the comment I had on the first line of the file: "Load all packages and save a new image SessionManager.... Note the *LACK* of the ending quote - arrrg ;-) |
Re: automated builds in D5Pro
|
|
In reply to this post by talios@gmail.com
Mark,
> I've finally got around to setting up this automated build process, and > have a base image with this new runtime manager in it, but the .st files > I'm filein don't seem to do anything, my script currently contains: > > SessionManager current saveImage: 'fresh.img'. > SessionManager current quit: 0. > > Short and sweet, doesn't do anything other than save the base image as a > fresh image, or in theory it should, but it doesn't seem to do anything. > > Is there something simple I'm missing from the filein script to make it > actually do something? ( selecting file-in from the menu does the same > "nothing" as well... The first (largely rhetorical) question I have is "what are you trying to accomplish?" It looks as though you want to go from a clean image to multiple executables. FWIW, I think it makes sense to split the tasks. Building a clean image is one job; deploying from it is another. In my case, I deploy several executables, and even on a ~2GHz machine, it takes a while (30 minutes or so) to strip everything and then build installers and herd them where they need to go for deployment to target machines. I have a batch build (IIRC, it is not in my posted goodies yet), that works a lot like SuiteBuilder. Given that stripping does very little to the development image (except get it ready for stripping the next executable in the suite), I don't see much benefit to stripping each app from a clean image. It should be enough to build the image, run tests etc. and then turn it loose on a batch build. Of course, I tend to save images as opposed to rebuilding every session, so YMMV. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |