You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by devroy <de...@gmail.com> on 2009/10/23 14:30:16 UTC
Build Scripts
Hi,
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?
Thanx
-Dev
--
View this message in context: http://www.nabble.com/Build-Scripts-tp26027423p26027423.html
Sent from the Subversion Users mailing list archive at Nabble.com.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410664
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Build Scripts
Posted by Tyler Roscoe <ty...@cryptio.net>.
On Fri, Oct 23, 2009 at 07:30:16AM -0700, devroy wrote:
> 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?
You want a Continuous Integration solution. There are hundreds of them
out there, probably a few written in shell. I have used CruiseControl in
the past and thought it was ok. People nowadays seem to like Hudson.
tyler
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410673
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Build Scripts
Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
I have posted what I can to
http://download.zeevee.com/dlimages/build.tar
but I will stick to my assertion that this is 90% custom to our
environment.
For windows, the top level script is startbuild.py. It is run by the
windows scheduled task service
For mac, cronbuild is invoked by cron
For linux, buildall is invoked by cron
Linux and mac share some tools in 'common' which is normally mounted as
/usr/global/bin
Unfortunately, I really can't sign up for supporting these.
JLM
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411485
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Build Scripts
Posted by Erik Hemdal <er...@comprehensivepower.com>.
> -----Original Message-----
> From: devroy [mailto:dev17.roy@gmail.com]
> Sent: Saturday, October 24, 2009 2:17 PM
> To: users@subversion.tigris.org
> Subject: RE: Build Scripts
>
>
> Hi Erik,
>
> are these shell scripts available..can you share these scripts..
>
You might find something useful at
http://subversion.tigris.org/tools_contrib.html.
A continuous-integration tool like Hudson might be what you want (I noticed
that mentioned in one of the earlier posts to this thread). If a shell
script is absolutely required, you probably will have to craft your own to
fit your environment.
Erik
> thanks
> -Dev
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411369
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Build Scripts
Posted by devroy <de...@gmail.com>.
Hi Erik,
are these shell scripts available..can you share these scripts..
thanks
-Dev
Jeremy Mordkoff-4 wrote:
>
>> From: Erik Hemdal [mailto:erik@comprehensivepower.com]
>> > From: devroy [mailto:dev17.roy@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
> your
>> 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
> a
>> scheduled job that checks for the most recent revision ('svnlook
> youngest'
>> can give you the most recently committed revision) and then checks out
> or
>> exports code for a fresh build.
>>
>> Erik
>>
> 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
> variable.
>
> 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.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410677
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@subversion.tigris.org].
>
>
--
View this message in context: http://www.nabble.com/Build-Scripts-tp26027423p26041638.html
Sent from the Subversion Users mailing list archive at Nabble.com.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411075
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Build Scripts
Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
> From: Erik Hemdal [mailto:erik@comprehensivepower.com]
> > From: devroy [mailto:dev17.roy@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
your
> 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
a
> scheduled job that checks for the most recent revision ('svnlook
youngest'
> can give you the most recently committed revision) and then checks out
or
> exports code for a fresh build.
>
> Erik
>
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
variable.
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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410677
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Build Scripts
Posted by Erik Hemdal <er...@comprehensivepower.com>.
> -----Original Message-----
> From: devroy [mailto:dev17.roy@gmail.com]
> Sent: Friday, October 23, 2009 10:30 AM
> To: users@subversion.tigris.org
> Subject: Build Scripts
>
>
> Hi,
>
> 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 your
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 a
scheduled job that checks for the most recent revision ('svnlook youngest'
can give you the most recently committed revision) and then checks out or
exports code for a fresh build.
Erik
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410668
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].