automated builds in D5Pro
Maxim Fridental
is there any official way to deploy a package from the command line?
Best regards,
Maxim Fridental
Ian Bartholomew
> 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
Christopher J. Demers
news:b69p16$32bnn$1...@ID-125734.news.dfncis.de...
> 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
Bill Schwab
> 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.
bi...@anest4.anest.ufl.edu
Bill Dargel
> "Maxim Fridental" <maxim.f...@straightec.de> wrote in message
> news:b69p16$32bnn$1...@ID-125734.news.dfncis.de...
> > 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 wda...@shoshana.com
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105 USA
Mark Wilden
news:3E8C0034...@shoshana.com...
>
> Hopefully others will find some useful ideas here.
If nothing else, running Dolphin -nosplash means a lot less water on the
carpet.
Christopher J. Demers
>
> > "Maxim Fridental" <maxim.f...@straightec.de> wrote in message
> > news:b69p16$32bnn$1...@ID-125734.news.dfncis.de...
> > > 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.
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
tal...@gmail.com
Mark Derricutt
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...
Mark Derricutt
>
> 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 ;-)
Bill Schwab
> 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.