You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Harshad <ha...@gmail.com> on 2008/09/06 11:28:59 UTC
Automatic build of source on every check-in
Hi,
I have recently installed and maintain a medium-sized svn repository at my
work-place. I wish to make sure that the trunk always compiles cleanly.
Searching on the web for pre-commit hooks that do this didn't reveal
anything.
I guess such a pre-commit script would need to do this:
* Check out the top of the trunk somewhere (or do an in-place update to
save some time)
* Patch this with the in-flight changes
* Build the working-copy
* Exit with non-zero value if build fails
Is anybody aware of such a script?
thanks,
Harshad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Chris Shenton <Ch...@nasa.gov>.
For continuous integration, check out "buildbot" (in Python) or
CruiseControl (in Java). Either of these can monitor a repo and then
do a build (or whatever) upon checkin, then alert people (including
the author of the last, change) when something fails.
The Pragmatic Programmers (pragprog.com) have a book that explains the
benefits of CI really really well, in a fun way: Pragmatic Project
Automation.
Re: Automatic build of source on every check-in
Posted by Harshad <ha...@gmail.com>.
Andreas Schweigstill wrote:
> Harshad schrieb:
>> However, if it is known that the build times are going to be small,
>
> How do you know that somebody didn't create a loop in the
> makefiles so the build process will never stop? It would be
> quite annoying to lock the whole repository by such an
> accidental check-in.
Timeouts maybe?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Harshad schrieb:
> However, if it is known that the build times are going to be small,
How do you know that somebody didn't create a loop in the
makefiles so the build process will never stop? It would be
quite annoying to lock the whole repository by such an
accidental check-in.
Regards
Andreas Schweigstill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Toby Thain <to...@telegraphics.com.au>.
On 7-Sep-08, at 1:06 AM, Harshad wrote:
> Gleason, Todd wrote:
>
>> And even if it doesn't tie up your local machine, if you "commit"
>> with
>> TeamCity and then update, what happens? Do your files stay in their
>> modified states (making a subsequent commit problematic) while the
>> build
>> runs? Or does something else happen? Does TeamCity flag your
>> changes
>> somehow and exclude them from a subsequent commit?
>
> I have never used it, so I don't know. I am not in favour of using it
> anyway; I just posted it as it came closest to what I originally
> wanted.
>
>> I think in general, I'd vote for a post-commit solution to this
>> problem.
>> If you want more control, I'd make people commit to a separate
>> "unstable" location, verify with the post-commit build, and then
>> automatically merge over to the "stable" location.
>
> Good idea. I assume that the post-commit hook would queue up a
> request to a
> build server and return immediately, so that the client doesn't
> block. The
> only negative I see in this is that it is a bit complex to
> implement than
> the pre-commit hook.
Seems like svk could help?
--Toby
>
> I would vote for a slight modification to the above though I don't
> know if
> it is feasible in subversion. It seems to work better when there is
> tag
> support (as implemented in CVS/Perforce). In this approach, commits
> to the
> trunk, or top-of-the-tree in general, are uncontrolled. But there is
> a "stable" tag which only gets updated if tests pass. This update can
> happen in the background by the build-server. And everybody is
> encouraged
> (disciplined) to always work off the stable tag.
>
> I have seen and used this in a previous life and it was very
> effective. But
> this was an in-house solution built around Perforce, with several
> person-months of effort behind it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Automatic build of source on every check-in
Posted by Harshad <ha...@gmail.com>.
Gleason, Todd wrote:
> And even if it doesn't tie up your local machine, if you "commit" with
> TeamCity and then update, what happens? Do your files stay in their
> modified states (making a subsequent commit problematic) while the build
> runs? Or does something else happen? Does TeamCity flag your changes
> somehow and exclude them from a subsequent commit?
I have never used it, so I don't know. I am not in favour of using it
anyway; I just posted it as it came closest to what I originally wanted.
> I think in general, I'd vote for a post-commit solution to this problem.
> If you want more control, I'd make people commit to a separate
> "unstable" location, verify with the post-commit build, and then
> automatically merge over to the "stable" location.
Good idea. I assume that the post-commit hook would queue up a request to a
build server and return immediately, so that the client doesn't block. The
only negative I see in this is that it is a bit complex to implement than
the pre-commit hook.
I would vote for a slight modification to the above though I don't know if
it is feasible in subversion. It seems to work better when there is tag
support (as implemented in CVS/Perforce). In this approach, commits to the
trunk, or top-of-the-tree in general, are uncontrolled. But there is
a "stable" tag which only gets updated if tests pass. This update can
happen in the background by the build-server. And everybody is encouraged
(disciplined) to always work off the stable tag.
I have seen and used this in a previous life and it was very effective. But
this was an in-house solution built around Perforce, with several
person-months of effort behind it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Automatic build of source on every check-in
Posted by "Gleason, Todd" <tg...@impac.com>.
Specifically, here is what I read that made me think otherwise:
If your changes pass, TeamCity (in cooperation with your IDE)
AUTOMATICALLY commits them to Version Control.
The "in cooperation with your IDE" is what concerned me. Is it
expecting your IDE to hang around?
And even if it doesn't tie up your local machine, if you "commit" with
TeamCity and then update, what happens? Do your files stay in their
modified states (making a subsequent commit problematic) while the build
runs? Or does something else happen? Does TeamCity flag your changes
somehow and exclude them from a subsequent commit?
I think in general, I'd vote for a post-commit solution to this problem.
If you want more control, I'd make people commit to a separate
"unstable" location, verify with the post-commit build, and then
automatically merge over to the "stable" location. And even this will
probably have plenty of issues, but it seems more sane to me.
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Harshad
Sent: Saturday, September 06, 2008 11:45 AM
To: users@subversion.tigris.org
Subject: RE: Re: Automatic build of source on every check-in
TeamCity does the commit directly, if it's a good commit. This page
makes it
clear:
http://www.jetbrains.com/teamcity/delayed_commit.html
That should reduce the round-trip time for the client and the problems
you
listed probably vanish.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Automatic build of source on every check-in
Posted by Harshad <ha...@gmail.com>.
Gleason, Todd wrote:
> I'd still have to ask how their pre-tested commit works. They say it
> works in conjunction with your IDE, which suggests that the way it works
> is something like this:
>
> 1. Your client sends the commit data to TeamCity instead of to the
> Subversion server.
>
> 2. TeamCity runs a build.
>
> 3. TeamCity tells your client that it's good to commit.
>
> 4. Your client commits to Subversion.
TeamCity does the commit directly, if it's a good commit. This page makes it
clear:
http://www.jetbrains.com/teamcity/delayed_commit.html
That should reduce the round-trip time for the client and the problems you
listed probably vanish.
However, if it is known that the build times are going to be small, a simple
pre-commit hook could replace mediators like TeamCity. I will probably cook
a script myself, since it doesn't look like its attempted before.
As a side note, Bazaar seems to have a good pre-commit infrastructure in
place:
https://bugs.launchpad.net/bzr/+bug/102747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Automatic build of source on every check-in
Posted by "Gleason, Todd" <tg...@impac.com>.
I'd still have to ask how their pre-tested commit works. They say it
works in conjunction with your IDE, which suggests that the way it works
is something like this:
1. Your client sends the commit data to TeamCity instead of to the
Subversion server.
2. TeamCity runs a build.
3. TeamCity tells your client that it's good to commit.
4. Your client commits to Subversion.
Granted, I may have made some poor assumptions here; TeamCity's web site
isn't all that explanatory. But if this is close to how TeamCity works,
then I see several possible problems:
1. Some build environments take several hours to run. You could be
waiting a long time to know if your commit was good. Worse, with lots
of other people committing, testing each and every commit could take
quite a bit of hardware.
2. What if your client goes down (possibly because you shut it down for
the evening or take your laptop home)? Does this prevent the commit?
3. What if you're busy making additional changes in the meantime? Can
they interfere with the commit (and possibly sneak in)? Or if you blow
away your working copy (or more likely switch/update it)?
4. What if you need others on your team to get your changes in shorter
order? I guess you can argue this is what private branches are for, but
not every team wants to use them all the time. And I doubt people want
to work around this manually either.
So I have a hard time imagining the corner cases not being more pain
than they're worth. It might be fine in a small environment, but this
level of overhead seems like something larger teams look for.
All that said, I wish I knew of a real silver bullet for continuous
integration.
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Harshad
Sent: Saturday, September 06, 2008 9:47 AM
To: users@subversion.tigris.org
Subject: Re: Automatic build of source on every check-in
Harshad wrote:
> Andy Levy wrote:
>
>> You're looking for a continuous integration tool.
>
> Nope. I am aware of them (Continuous integration by Martin Fowler and
the
> Cruise Control software). I am specifically interested in building the
> system _before_ the commit is accepted.
>
A lot of searching and I still haven't found any such script for SVN.
There
are some third-party solutions like TeamCity:
http://www.jetbrains.com/teamcity/features/continuous_integration.html
(See their pre-tested commit section)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Harshad <ha...@gmail.com>.
Harshad wrote:
> Andy Levy wrote:
>
>> You're looking for a continuous integration tool.
>
> Nope. I am aware of them (Continuous integration by Martin Fowler and the
> Cruise Control software). I am specifically interested in building the
> system _before_ the commit is accepted.
>
A lot of searching and I still haven't found any such script for SVN. There
are some third-party solutions like TeamCity:
http://www.jetbrains.com/teamcity/features/continuous_integration.html
(See their pre-tested commit section)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Harshad <ha...@gmail.com>.
Thanks Andy for your response.
Andy Levy wrote:
> You're looking for a continuous integration tool.
Nope. I am aware of them (Continuous integration by Martin Fowler and the
Cruise Control software). I am specifically interested in building the
system _before_ the commit is accepted.
> You do NOT want to
> be compiling your source in the pre-comit hook; it'll slow everything
> down - can you imagine having to wait 20 minutes for your commit to
> complete because you're waiting on a compile?
We use parallel builds and the compile time is about 1 minute. The total
time to run the regressions is about 20 seconds. We intend to further
reduce the time using a small cluster of build servers.
Further, we plan to make large development efforts on separate branches,
which _won't_ have the pre-commit hook. Only the trunk would have the hook
and those commits should be far fewer.
cheers,
Harshad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automatic build of source on every check-in
Posted by Andy Levy <an...@gmail.com>.
On Sat, Sep 6, 2008 at 07:28, Harshad <ha...@gmail.com> wrote:
> Hi,
>
> I have recently installed and maintain a medium-sized svn repository at my
> work-place. I wish to make sure that the trunk always compiles cleanly.
>
> Searching on the web for pre-commit hooks that do this didn't reveal
> anything.
>
> I guess such a pre-commit script would need to do this:
> * Check out the top of the trunk somewhere (or do an in-place update to
> save some time)
> * Patch this with the in-flight changes
> * Build the working-copy
> * Exit with non-zero value if build fails
>
> Is anybody aware of such a script?
You're looking for a continuous integration tool. You do NOT want to
be compiling your source in the pre-comit hook; it'll slow everything
down - can you imagine having to wait 20 minutes for your commit to
complete because you're waiting on a compile?
Instead, the CI system builds the source after each commit and sends
out an email informing the whole team whether the build was successful
or not, and if not, who broke the build.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org