> 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
> 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
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: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-23 17:38:13 CEST