Clean builds in continuous integration
Asked Answered
C

5

7

We use a CruiseControl.Net/NAnt/Subversion stack for CI. Doing a fresh checkout for every build is way too time-consuming, so currently we just do an update on a working copy. However, this leaves the possibility that orphaned files may remain in the working copy, after being deleted in source control. We have tried using the NAnt delete task just to remove all code source files before an update, but this can corrupt the working copy. Does anyone know a fast way to run a build on a clean and up-to-date working copy? EDIT: We are on SVN 1.3.2

Chlamydeous answered 18/9, 2008 at 13:3 Comment(0)
D
5

If you do just 'update', SVN will delete all the files that were deleted in the source control. However files that were created during build process might still be there and might interfere with new build. I'm not sure if SVN has a command to delete them but I guess you could do that with a little script, SVN definitely could tell you which files are under source control and which aren't.

Darrelldarrelle answered 18/9, 2008 at 13:9 Comment(0)
L
3

We had a similar issue with our CC implementation.

Our solution... We had already crafted a 3:00 AM nightly build that executed longer running integration tests in addition to the base unit tests. We simply decided to make that 3:00 AM build a fully clean build on a fresh tree. As it was the middle of the night, it rarely affected anyone. All other "normal" check-ins ran incremental builds.

Ludovick answered 18/9, 2008 at 13:16 Comment(0)
B
1

If there are orphaned files left in your working copy having done an svn update then there's a bug in your Subversion version.

Buchner answered 18/9, 2008 at 13:6 Comment(0)
T
1

You might do a daily full build, and leave the build on check-in as is. Also, for deployment builds, it is probably a good idea to always use a clean complete build.

Typhoeus answered 18/9, 2008 at 13:7 Comment(0)
G
1

The only way I can think of is having two copies on the build server. First you update on the first location. You delete the second location. Copy first to second and then build in the second location. That way you always start from a clean build.

You might want to look at why your checkout is taking so long. I've used the same buildserver stack and never had problems with this. Subversion usually took less time than the build itself.

Gates answered 18/9, 2008 at 13:9 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.