I'm using cruisecontrol.net for integration builds along with external source control. The source control (GETMODS) script fails, this is fine and I know why, but the build stays green for some reason when it's expected to fail. CruiseControl shows the exception on the output window below, so why doesn't the build fail?
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed:
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute
(ProcessInfo processInfo)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ExternalSourceControl.GetMod ifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResultthisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
I guess the reasoning would be that the source control block is only used:
to check if there are any changes in the source code which require a rebuild, and
to get all the source code needed for the build.
If this action fails it has nothing to do with the source code and the commits to it. It's an infrastructural problem that prevents the build from happening at all therefore technically the build hasn't fails. It hasn't even started.
With a version control block inside cc.net, it search for repository modification.
If cc.net is unable to contact the repository, it can't start the job.
The result is an exception.
If you want to ignore this, this can help (simple retry counter) !
Can we tell CruiseControl.NET to ignore source control timeout errors?
<maxSourceControlRetries>5</maxSourceControlRetries>
<stopProjectOnReachingMaxSourceControlRetries>true</stopProjectOnReachingMaxSourceControlRetries>
<sourceControlErrorHandling>ReportOnRetryAmount</sourceControlErrorHandling>
I believe this is a recent change to ccnet. We are running two versions on separate machines. Version 1.4 breaks the build if it can't get to our svn repository, but version 1.5 will not break the build. I haven't looked into it yet, but there may be a switch to force 1.5 to break on failure to retrieve code.
Related
As mentioned in the question, I often encounter the situation shown in the picture below:
Problems demonstrate
I'm using the Clean... directive here, not the Reconcile Offline Work...directive
Clean...
This bug was fixed in the server in release 2016.2:
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
#1382996 (Job #74886, #86396) **
'p4 clean' would fail to sync files when needed when they
are exclusively opened by another client. This has been
fixed.
Double check that you're on release 2016.2+ of the server; if you are, you should be at the very least be able to use p4 clean as a workaround (e.g. by adding it as a custom tool to P4V).
I had CC .NET 1.4.4 previously and everything was working fine. I
upgraded it to 1.6.789.1 and now and I get below exception in the log
file at Program Files (x86)\CruiseControl.NET\server\Private Branch
\Artifacts\buildlogs (I use clear case, but I guess that doesn't
matter, just FYI.)
I would really appreciate if someone could help me with this, as I
spent enough time on this.
<build date="2012-03-16 15:31:19" buildtime="00:00:00"
buildcondition="ForceBuild" />
<exception><![CDATA[System.InvalidOperationException: Cannot start
process because a file name has not been provided.
at System.Diagnostics.Process.Start()
at
ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.StartProcess()
at
ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.Run()
at
ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.Execute(ProcessInfo
processInfo)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo
processInfo)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.ClearCase.GetModifications(IIntegrationResult
from, IIntegrationResult to)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.FilteredSourceControl.GetModifications(IIntegrationResult
from, IIntegrationResult to)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModificationsWithLogging(ISourceControl
sc, IIntegrationResult from, IIntegrationResult to)
at
ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl
sourceControl, IIntegrationResult lastBuild, IIntegrationResult
thisBuild)
at
ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult
from, IIntegrationResult to)
at
ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest
request)]]></exception>
</cruisecontrol>
Using CC with ClearCase can matter (for instance when used with CCRC, the ClearCase Remote Client), if the update process of your snapshot view (or your web view in the case of CCRC) has any issue to complete.
(speculation:)
Considering ClearCase.GetModifications is called, I suppose the name of the view is no longer provided, maybe because the CC process used to deduce said name from the current view directory (cleartool lsview -cview). If that CC process launches from the wrong directory (ie one outside of the ClearCase view), it would no longer be able to get back the right ClearCase view name.
Ok, here is the fix for this issue. Thanks VonC for throwing some light on it and it was one of your older post that helped me fix this.
With CC.Net 1.4 and 1.5 i never had <executable> parameter under <sourcecontrol> section, but after looking at the following thread - CruiseControl.NET and Clearcase configuration, i thought of using the full path of cleartoo.exe file as given below and it fixed the problem, build ran fine. It looks like for CC.NET 1.6 mentioning the full path of the source control exe is mandatory.
<executable>C:\Program Files (x86)\Rational\ClearCase\bin\cleartool.exe</executable>
I'm using CC.net on against a Source Safe database, and have a problem that someone deleted some files from the database, and the deleted files weren't removed. I didn't see a config switch or anything that I could set for it to clear the code directory prior to building.
Am I missing something?
As Alex says there is a CleanCopy flag in the source code block. However, my situation was a little different. I use subversion and I found the CleanCopy flag was NOT doing what it said it would on the box.
To solve the problem I added a task which runs a batch file that clears out the build's working copy prior to checkout. It is a bit slower (about 1 min for code base of 400Mb) but guarantees no old code.
Kindness,
Dan
All you need to do is set CleanCopy to true in your source control block. The documentation is very clear on this. The above answer is the wrong way.
I have created a custom labeller for CC.Net which is working almost perfectly, however it appears that the labeller runs before the application is built. The issue I have with this is that I want my build label to be that of my AssemblyVersion.
I have the following in my labeller:
public string Generate(IIntegrationResult previousResult)
{
if (File.Exists(this.OutputExecutable))
{
Assembly assembly = System.Reflection.Assembly.Load(System.IO.File.ReadAllBytes(this.OutputExecutable));
string version = assembly.GetName().Version.ToString();
assembly = null;
return version;
}
else
{
return "0.0.0.0";
}
}
This gets the version of the provided DLL/Exe so that I can use it as my build label. I'll probably go on to add the actual build number in later, but I just want to get this bit working first.
The issue is that my Revision number is in the format 2.0.93601.254 major.minor.date.svnrevision. When a check-in occurs, I build the codebase and the revision number would go to 2.0.93601.255. Unfortunately CC.Net still produces a Build Label of .254 until a force build is called when it will be successfully changed to .255.
Is there any way I can force the labeller to wait until the build process is complete? Or are there any alternative ways I should be doing this?
The answer to this I believe is no. What I did was to create my own console application that updates the assemblyinfo.cs file before the MSBuild task in CC.Net's project configuration. Problem (kind of) solved.
This is backwards from how most people do this; you make ccnet set the version of your code & assemblies automatically, pulling the version from config and say the svn rev #.
This is why it is critically important the labeller runs before tasks.
I searched a lot but i didn't find a solution for my problem.
I use CruiseControl.NET (1.4.4). My project (in ccnet.config) load a repository from a cvs server to a local repository, and launch some executables (msbuild, NUnit...).
I use a trigger (Interval or Schedule Trigger), that launch regularly my project. But if my project has not been modified, it always launch all next tasks. And I would like to avoid it. So i want to launch my project only if a commit has been detected.
Is there any solution for it please?
Thanks
Olivier
Your trigger needs to specify IfModificationExists:
<intervalTrigger
name = "dave"
seconds = "30"
buildCondition = "IfModificationExists" />
Although buildCondition="IfModificationExists" is the default anyway, so as long as its not set to ForceBuild you should be fine.
EDIT:
The URL Trigger might be of some use to you. You can set your svn server to modify a page on commmit and the CC.Net checks the page to see if it has changed, thus not getting all the files.
I start my project as below, which ensures that the tasks get executed only if there are modifications.
Hope this helps,
Anders, Denmark
Edited: My code excerpt didn't make it to the page - I've tried to replace less-than, bigger-than with brackets.
[project name="SpilMerePool" queue="Q2" queuePriority="1"]
[sourcecontrol type="svn"]
[trunkUrl]https://ajf-ser1.ajf.local:8443/svn/SpilMerePool/trunk[/trunkUrl]
[workingDirectory]c:\from_vc\SpilMerePool[/workingDirectory]
[executable]C:\Program Files\VisualSVN Server\bin\svn.exe[/executable]
[username]username[/username]
[password]password[/password]
[/sourcecontrol]
Just use IntervalTrigger, like this:
<triggers>
<intervalTrigger />
</triggers>
You can also add an modificationDelaySeconds, to wait for a number of seconds before starting the build after the last commit.
<modificationDelaySeconds>30</modificationDelaySeconds>
Thank you Anders Juul abd Andy for your quick answers.
By using the intervalTrigger with "IfModificationExists" build condition, the project must be loaded each time (it's logical ^^). But my project size is about 450Mo. So it's a little long.
So my last question is : can we execute all builds and next tasks when a commit command has been detected? (without loading all files, in CruiseControl).
I use TortoiseCVS (version 1.10.10). Maybe we can force CruiseControl project to be lauched after a commit?