On Wed, Apr 6, 2011 at 2:53 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Wed, Apr 06, 2011 at 13:57:43 +0200:
>> Another suggestion: we use IntelliJ IDEA (Java IDE) and TeamCity
>> (continuous build system). With this setup, there is a Teamcity
>> feature (which we can use from within the IDE) called "Pre-tested
>> commit". It allows you to perform a "remote build" on TeamCity with
>> your local changes integrated. If the build is successful, you can let
>> those changes be committed automatically (optionally, you can let it
>> ask you for confirmation first).
> The procedure you just described embeds a race condition. (someone
> else's commit getting started after you started your remote building and
> finishing before you commit) What does TeamCity about it?
Hm, you're right. That must be the reason why I never used it ;-).
But you're right, just after I sent my mail I was thinking the same
(what would happen if someone else did a "pre-tested commit" (or just
a regular commit) at around the same time as my "remote build" is
running?). I guess TeamCity would just start my "remote build" with
the latest sources it has (checked out from version control (which
should be updated after every commit) at the time.
OTOH, the same problem would probably come up if you'd try to do this
in a pre-commit hook (unless someone decides to synchronize those
pre-commit-hook-builds, but wow, then it would be even more blocking
:)). And the same problem is also there if you ask your developers to
perform a private local build and set of unit tests before they
If I were to use this feature in my organisation, I guess I would
handle this pragmatically: there should still be an automatic
build+tests running on TeamCity (or whatever continuous build system)
running builds after every commit. This can catch any problems with
concurrent-commits after the fact ...
Received on 2011-04-06 15:29:55 CEST