are these shell scripts available..can you share these scripts..
Jeremy Mordkoff-4 wrote:
>> From: Erik Hemdal [mailto:erik_at_comprehensivepower.com]
>> > From: devroy [mailto:dev17.roy_at_gmail.com]
>> > Are there buildscripts written in shell(preferably)that would
>> > sync to the depot based on a build label or change number or
>> > triggered upon a change to depot files and build the
>> > application and log the build results in a log file?
>> A lot depends on your platform and your environment, of course. If
>> Linux server is managing Windows code, you might have to do the work
> on a
>> Windows client.
>> You might be able to do this with a post-commit hook, or perhaps with
>> scheduled job that checks for the most recent revision ('svnlook
>> can give you the most recently committed revision) and then checks out
>> exports code for a fresh build.
> I have such scripts running on windows(python), linux (bash) and mac
> (sh), but I have to agree that the vast majority of the code is dealing
> with the specifics of how we build and where we store results. But I
> have some advice --
> Put the build scripts under source control where ever possible. Our top
> level scripts that are OUTSIDE source control basically only do the
> following --
> For each branch (and/or trunk) that is 'active'...
> 1- Look to see if there has been a commit on the branch in question
> since the last build but no commits in the last 5 minutes. Sometimes
> developers commit fixes in pieces. I know they're not supposed to, but
> they do. This gives them 5 minutes to finish up.
> 2- Checkout a clean copy of the branch in question. Always a clean copy.
> If this fails, send email to release engineering/IT and exit.
> 3- Invoke a build script that's inside source control. This way changes
> made to the build process will not break the build for older releases.
> Redirect ALL output to a file.
> 4- Check the return code from the build and look for the last file that
> it should produce. If all looks good, copy the files to someplace that
> QA can find them (our QA has automated tests that monitor an NFS server
> waiting for new files to show up).
> 5- Generate a report listing all commits since the last GOOD build and
> send mail. If the build failed, we send the mail to anyone that did a
> commit plus release and we also include the last 400 lines from the
> build log. If the build succeeded, we send an email to all of software
> development and QA with just the list of commits.
> Our build scripts vary widely by product. On linux, it is a bash script
> that calls make. On windows it is a python script that calls make and
> some windows command files. On macs, it is a SH script that calls make.
> Anytime you type a pathname, filename, drive letter, etc. try to find a
> way to either calculate it, or use a environment variable. Okay, the
> string /branches/ that you use to build an SVN directory name can
> probably be hard-coded, but just about anything else should be a
> I use aliases for EVERY system in my network. svn.zz1.local,
> ftp.zz1.local, bugz.zz1.local, wiki.zz1.local are all aliases for
> zaz1.zz1.local, but someday I'll buy zaz2.zz1.local and half of those
> services will move but only my DNS server will have to change.
> Good luck. This is always worth the effort.
> To unsubscribe from this discussion, e-mail:
View this message in context: http://www.nabble.com/Build-Scripts-tp26027423p26041638.html
Sent from the Subversion Users mailing list archive at Nabble.com.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-24 20:18:49 CEST