Label triggered CCnet build

[ajj3085]

Any idea why a label would trigger a CC.net build on vaultpro? This caused the build to fail, because the same label as before was reused (I believe because the folder version didn't change) and of course vault disallows that.

This is the modification block:
- <modifications>
- <modification type="Label">
<filename>trunk</filename>
<project>$/djs</project>
<date>2011-01-09 10:02:05</date>
<user>ajj3085</user>
<comment>Build 4.0.0.1520</comment>
<changeNumber>0</changeNumber>
<version>65</version>
<url>https://remote.greatlynxsoftware.com/Va ... xid=0</url>
</modification>
</modifications>

This is my ccnet project configuration:

<project name="Project - Trunk">
<workingDirectory>d:\BuildServer\x\project\trunk\</workingDirectory>
<artifactDirectory>d:\BuildServer\x\project\trunk\Artifacts</artifactDirectory>
<state type="state">
<directory>D:\BuildServer\State</directory>
</state>
<triggers>
<intervalTrigger name="continuous" seconds="30" initialSeconds="30" />
</triggers>

<sourcecontrol type="filtered">
<sourceControlProvider type="vaultproplugin" autoGetSource="true" applyLabel="false">
<username>user</username>
<password>pass</password>
<host>vault.domain.com</host>
<repository>Repo</repository>
<folder>$/x/trunk</folder>
<ssl>true</ssl>
<useWorkingDirectory>true</useWorkingDirectory>
<workingDirectory>build</workingDirectory>
<deleteItemsThatAreNotInTheRepository>true</deleteItemsThatAreNotInTheRepository>
</sourceControlProvider>
<exclusionFilters>
<pathFilter>
<pattern>$/x/trunk/bin/**/*.*</pattern>
</pathFilter>
<pathFilter>
<pattern>$/x/trunk/AssemblyVersionInfo.cs</pattern>
</pathFilter>
</exclusionFilters>
</sourcecontrol>

<tasks>
<msbuild>
<executable>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe</executable>
<projectFile>.\build\x.msbuild</projectFile>
<buildArgs>/noconsolelogger /p:BuildServerRoot=D:\BuildServer\ /p:VaultPassword=pass</buildArgs>
<timeout>900</timeout>
<logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
</tasks>

<publishers>
<xmllogger />
<statistics />
</publishers>

<labeller type="assemblyVersionLabeller">
<major>4</major>
<minor>0</minor>
<build>0</build>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
</project>

[Beth]

Can you perform a Show History on your project to confirm that there were no check-ins right around the time that the label was added?

[ajj3085]

The build script commits to a /bin folder after a successful build, and I have a label task immediately after the commit. I'm using the filtered source control block to filter out changes to that folder though. Perhaps the only modification after the filter is the label?

I did find though the applyLabel though for the vaultpro source control block. Maybe I should be using that instead?

[ajj3085]

Any update on this?

I checked my CCNet log file, and labels are clearly coming back as part of the modification list:
2011-01-11 20:17:08,398 [x- Trunk:DEBUG] Modification VaultProModification: (LastSuccessRootFolderVersion=931,FromFolderVersion=931,RootFolderVersion=932,RootFolderPath=$/x/trunk,BugIDs=,Type=Label,FileName=trunk,FolderName=$/x,ModifiedTime=1/9/2011 10:03:50 AM,UserName=user,ChangeNumber=0,Version=932,Comment=Build 2.3.0.1521,Url=https://vault.domain.com/VaultService/V ... ilAddress=) was accepted by the filter specification.

I think this was a bug that was fixed a while ago, but that plugin was using the command line client.

[ajj3085]

Another update. As a workaround, I was able to use an ActionFilter to filter out the Label action. This is not ideal though, as it needs to be done for every CC.net project, and I'm not seeing a use case for building when a label has been applied to a folder.

The vaultplugin that comes withi CC.net by default sends -exclude label to the history command; I think the one provided by SourceGear should do the same.

Thanks
Andy

[Beth]

Is your /bin directory in your Vault repository?

[ajj3085]

Yes, so that I can pull down any build and deploy it.

[Beth]

I don't think our plug-in works with filtering, so it's likely that it's the /bin update that is really kicking off the build. You could test this out by commenting out the label piece or removing it, then check in a test change and see if you still get the second build after the commit to /bin.

[ajj3085]

It does work with filtering, and I can see this via the CC.Net logs. It was working fine until I added the labeling at the end of the commit. It also works if I use an action filter to filter the label in addition the binaries.

[Beth]

Would it work for you to instead label the project first, then perform a Get on that label, then perform the build?

[ajj3085]

[quote="Beth"]Would it work for you to instead label the project first, then perform a Get on that label, then perform the build?[/quote]

Not really. The point of having the outputs included is so that I can do the build and if successful commit the bins and label.. so that I can get specific builds I want to deploy.

[Beth]

I'm not sure why this would be happening, but I will log this as a bug anyway so that our developers are aware of it. Thank you for reporting this.

F: 15851