Hi can you run the following code?
string workingDirectory = "D:\Builddirectory\Aggregates"; Console.Writeline(Directory.Exists(workingDirectory)); Console.Writeline(Directory.GetDirectories(workingDirectory, ".svn").Length); replace it with the real working folder. This is part of the code that ccnet executes to determine if a working folder is a SVN workind folder. I would expect to see true 1, describing from your mails, but am hoping on something else. with kind regards Ruben Willems On Tue, Jun 23, 2009 at 10:03 PM, Ruben Willems <[email protected]>wrote: > Hi > > > I did a check, and a trailing \ does not have any influence :-( on the > check > Too bad, this would have been a nice candidate though. > so we're back to square 1. > > > with kind regards > Ruben Willems > > On Mon, Jun 22, 2009 at 6:16 PM, Yop83 <[email protected]> wrote: > >> >> I am indeed running 1.4.4 SP1. >> I double-checked for the warning and I found it. >> I missed it the first time around because of the fact that it is NOT >> present when a build is forced via the dashboard (I was testing that >> way). >> The warning is present when the interval trigger is run, though. >> >> Here is the output of an non-forced integration (the warning is on the >> second line): >> "2009-06-22 11:58:02,246 [Aggregates - Release 1.0:INFO] Project: >> 'Aggregates - Release 1.0' is first in queue: 'Aggregates - Release >> 1.0' and shall start integration. >> 2009-06-22 11:58:02,293 [Aggregates - Release 1.0:WARN] "D:\Build >> directory\Aggregates" is not a svn working folder >> 2009-06-22 11:58:02,387 [Aggregates - Release 1.0:DEBUG] Starting >> process [svn] in working directory [D:\Build directory\Aggregates] >> with arguments [log https://svn.mycompany.com/svn/Aggregates/Release-1.0 >> -r >> <https://svn.mycompany.com/svn/Aggregates/Release-1.0%0A-r>"{2009-06-15T15:11:16Z}:{2009-06-22T15:58:02Z}" >> --verbose --xml -- >> non-interactive --no-auth-cache] >> 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] <? >> xml version="1.0"?> >> 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] >> <log> >> 2009-06-22 11:58:02,653 [1820:DEBUG] [Aggregates - Release 1.0 svn] </ >> log> >> 2009-06-22 11:58:02,856 [Aggregates - Release 1.0:DEBUG] No >> <logentry>s found under <log>. >> 2009-06-22 11:58:02,856 [Aggregates - Release 1.0:INFO] No >> modifications detected." >> >> Obviously, the warning is a false positive because Subversion is able >> to tell that there is no modifications (meaning that my working copy >> is up-to-date, which it is). >> A quick look in that folder confirms that there is a ".svn" folder. >> Also, note that CCNet did the initial check-out of that working copy. >> >> While checking the logs, I checked out the logs for our other >> projects: most, if not all, also exhibit this warning. >> Maybe there is something wrong with my configs after all? >> >> Could it be that the missing trailing slash in the directory string >> ("D:\Build directory\Aggregates") could cause this warning? >> Also, I cleaned-up the paths in my examples (to remove our company >> name). The real path contains 102 characters. >> Could the length of the path be a source of issues? >> >> Thanks. >> >> > On Jun 19, 5:49 am, Ruben Willems <[email protected]> wrote: >> > Hi >> > >> > are you sure that you're running SP1 on the build server, >> > because there is a log statement : >> > Util.Log.Warning(string.Format("{0} is not a svn working folder", >> wd)); >> > >> > so when the svn is not run, this should be in the log. >> > >> > can you double check this? >> > >> > with kind regards >> > Ruben Willems >> > >> > On Fri, Jun 19, 2009 at 9:45 AM, Ruben Willems <[email protected] >> >wrote: >> > >> > > Hi >> > >> > > your config looks ok :-( >> > > the only thing preventing the cleanup / revert from running is the >> > > following : >> > > the code checks that the working folder has a subfolder .svn or _svn >> > > if not found, do no execute >> > >> > > now comes the trick : which folder is ccnet checking? >> > >> > > I'll add more debug.log statements in the code, so in a future version >> I >> > > know what ccnet is doing where >> > >> > > if you view the project configuration via the validator / dashboard / >> > > project configuration, >> > > which folder do you see in the working directory IN the source control >> > > block? >> > >> > > with kind regards >> > > Ruben Willems >> > >> > > On Thu, Jun 18, 2009 at 8:58 PM, Yop83 <[email protected]> >> wrote: >> > >> > >> I uploaded the project config here: >> > >> > >> >> http://www.mediafire.com/?sharekey=14cae1bed568604b4c17ca8801618ef7e0... >> > >> (The file is called "Aggregates.xml") >> > >> > >> We have multiple project files on our instance of CCNet, so we are >> > >> using <cb:include href="myProject.xml"> tags in the main ccnet.config >> > >> file. >> > >> That is why I did not post it: all of the logic (except a couple of >> > >> variables declaration) is done in the project config file. >> > >> > >> I hope this file can answer your questions. >> > >> If you need more info, don't hesitate. >> > >> > >> > On Jun 15, 2:31 pm, Ruben Willems <[email protected]> wrote: >> > >> > Hi >> > >> > >> > can you post your ccnet.config of the involved project? >> > >> > I'm intrested in the following : >> > >> > ° do you have a working folder set at the project level ? >> > >> > ° your svn section >> > >> > >> > with kind regards >> > >> > Ruben Willems >> > >> > >> > On Mon, Jun 15, 2009 at 5:54 PM, Yop83 <[email protected]> >> wrote: >> > >> > >> > > I'm using CCNet 1.4.4 SP1 (not a clean install, but an update). >> > >> > >> > > A project got stuck in the "exception" state recently because the >> > >> > > working copy was locked. This was a perfect opportunity for me to >> add >> > >> > > the new <cleanUp>true</cleanup> tag in the source control block >> of >> > >> > > that project. >> > >> > >> > > Of course it wasn't that easy... >> > >> > >> > > 1. I added the <cleanUp>true</cleanup> under the sourcecontrol >> block >> > >> > > of the affected project. >> > >> > >> > > 2. I insured the configuration was updated (by going in the >> "Project >> > >> > > Configuration" tag of the web dashboard and seeing that the tag >> is >> > >> > > correctly set to true). >> > >> > >> > > 3. I forced a build using the web dashboard. >> > >> > >> > > EXPECTED RESULTS: >> > >> > > 4. The build succeeds because of the cleanup command is run >> against >> > >> > > the working directory. >> > >> > >> > > ACTUAL RESULTS: >> > >> > > 4. The build still fails with the "working copy locked" error. No >> > >> > > changes. >> > >> > >> > > SERVER LOG: >> > >> > > Here is the server log related to the force build. As you will >> see, >> > >> > > there is no mention of the cleanup command in the SVN arguments: >> > >> > > "2009-06-15 11:06:49,658 [Aggregates - Release 1.0:INFO] >> Building: >> > >> > > Dashboard triggered a build (ForceBuild) >> > >> > > 2009-06-15 11:06:49,658 [Aggregates - Release 1.0:DEBUG] Starting >> > >> > > process [svn] in working directory [D:\Build >> directory\Aggregates] >> > >> > > with arguments [update "D:\Build directory\Aggregates" --non- >> > >> > > interactive --no-auth-cache] >> > >> > > 2009-06-15 11:06:49,705 [17060:DEBUG] [Aggregates - Release 1.0 >> svn] >> > >> > > svn: Working copy 'D:\Build directory\Aggregates' locked >> > >> > > 2009-06-15 11:06:49,720 [17060:DEBUG] [Aggregates - Release 1.0 >> svn] >> > >> > > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' >> for >> > >> > > details) >> > >> > > 2009-06-15 11:06:50,033 [Aggregates - Release 1.0:INFO] >> Integration >> > >> > > complete: Exception - 15/06/2009 11:06:49 AM" >> > >> > >> > > CONFIGURATION OF OUR SERVER: >> > >> > > CCNet 1.4.4 SP1 >> > >> > > SVN 1.6.2 >> > >
