For myself, I think I'd just end up going to the build server and
scheduling the other builds right away anyways. I want to know as
soon as possible if my changes are having a detrimental effect
anywhere throughout the system.
What is the main concern people have? That the SQL Server build gets
delayed? My understanding is that it's general policy to not commit
things that break that test suite anyways, so I can't imagine it would
make much difference.
Ideally, everything would just run faster, but if we can't have it run
faster, I'm personally good with it just happening sometime soon after
each commit. It's possible that grouping the commits together by
adding a delay could improve some situations, but in general the
commits to NH aren't that frequent, so I feel that having the system
do a full build after each commit is quite reasonable.
Patrick Earl
On Wed, Jul 27, 2011 at 1:45 PM, Stephen Bohlen <[email protected]> wrote:
> Is it feasible to consider decoupling the database-specific tests from the
> commit-triggered-build altogether and running the database-specific tests as
> part of either a regularly-scheduled once-per-day build or as an on-demand
> build? If they increase the length of the CI feedback loop unacceptably,
> this might permit us to both benefit from having them wired up but also
> sidestep the negatives associated with them.
>
> Thoughts on the viability of this approach --?
>
> Steve Bohlen
> [email protected]
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
