CruiseControl.net 1.4.4 / Fortress 2.0
Moderator: SourceGear
CruiseControl.net 1.4.4 / Fortress 2.0
We just upgraded from Fortress 1.1.4 to 2.0.1. Our build servers (CruiseControl.NET 1.4.4 SP1) haven't worked correctly since then.
The build fails with the following exception after all the tasks have completed:
System.NullReferenceException: Object reference not set to an instance of an object.
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.GetVaultClientFolder(String repositoryFolderPath, VaultClientFolder& vcf)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.Label(String repositoryFolderPath, Int64 folderVersion, String label, String labelComment)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressVaultSourceControl.LabelSourceControl(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
As a temporary workaround, the "get" task was modified to apply the label instead of using "applyLabel=true" with the Fortress Client plug-in. The builds now succeed, but the projects are no longer kicking off with the IfModificationExists. We have to manually kick off the builds after each check-in, or set up a scheduled forcebuild task.
The build fails with the following exception after all the tasks have completed:
System.NullReferenceException: Object reference not set to an instance of an object.
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.GetVaultClientFolder(String repositoryFolderPath, VaultClientFolder& vcf)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.Label(String repositoryFolderPath, Int64 folderVersion, String label, String labelComment)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressVaultSourceControl.LabelSourceControl(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
As a temporary workaround, the "get" task was modified to apply the label instead of using "applyLabel=true" with the Fortress Client plug-in. The builds now succeed, but the projects are no longer kicking off with the IfModificationExists. We have to manually kick off the builds after each check-in, or set up a scheduled forcebuild task.
Re: CruiseControl.net 1.4.4 / Fortress 2.0
Are there any errors in the Vault server log that correspond to the time the build process fails?
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support
Re: CruiseControl.net 1.4.4 / Fortress 2.0
No, there is no corresponding error in the server log.
Re: CruiseControl.net 1.4.4 / Fortress 2.0
During the upgrade, did you switch from the old CLC-based Cruise Control support to the plugin? Would you be willing to mail your ccnet.config file to support at sourcegear dot com?
Subscribe to the Fortress/Vault blog
Re: CruiseControl.net 1.4.4 / Fortress 2.0
We did not switch from CLC-based to the plugin during the upgrade. We will email the config.
Re: CruiseControl.net 1.4.4 / Fortress 2.0
The fix that we implemented was to specify the repository in the ccnet config file. The Fortress 2.0 plug-in apparently does not use the repository specified with rememberlogin even though it is documented to behave that way.
Re: CruiseControl.net 1.4.4 / Fortress 2.0
Thank you for providing the update.
Beth Kieler
SourceGear Technical Support
SourceGear Technical Support