You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(33) |
Jun
(44) |
Jul
(40) |
Aug
(23) |
Sep
(26) |
Oct
(41) |
Nov
(37) |
Dec
(42) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(40) |
Feb
(58) |
Mar
(81) |
Apr
(94) |
May
(77) |
Jun
(83) |
Jul
(55) |
Aug
(118) |
Sep
(51) |
Oct
(193) |
Nov
(77) |
Dec
(17) |
| 2005 |
Jan
(56) |
Feb
(87) |
Mar
(83) |
Apr
(155) |
May
(115) |
Jun
(157) |
Jul
(90) |
Aug
(87) |
Sep
(145) |
Oct
(56) |
Nov
(105) |
Dec
(88) |
| 2006 |
Jan
(56) |
Feb
(93) |
Mar
(30) |
Apr
(46) |
May
(46) |
Jun
(16) |
Jul
(33) |
Aug
(54) |
Sep
(47) |
Oct
(21) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(6) |
3
(1) |
|
4
|
5
|
6
(3) |
7
(1) |
8
(2) |
9
|
10
|
|
11
|
12
|
13
(1) |
14
(1) |
15
(3) |
16
|
17
(1) |
|
18
|
19
(4) |
20
(3) |
21
(7) |
22
(4) |
23
(4) |
24
|
|
25
|
26
(2) |
27
(11) |
28
|
29
|
30
(1) |
31
|
|
From: <ji...@pu...> - 2004-07-30 22:07:31
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-129 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-129 Summary: exception during VSS doesn't show up in log Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Builder Versions: 1.0 Assignee: Reporter: Created: Fri, 30 Jul 2004 3:03 PM Updated: Fri, 30 Jul 2004 3:03 PM Environment: Windows 2000 .NET 1.1 Description: [project:Error]: Exception: Source control operation failed: Set c:\temp\builds\project as the default folder for project $/?(Y/N)N A writable copy of c:\temp\builds\project\project.build already exists . Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE get $/ -R -Vd7/30/2004;2:51P -Yccnet,ccnet -I-N ---------- ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: Set c:\temp\builds\project as the default f older for project $/?(Y/N)N A writable copy of c:\temp\builds\project\project.build already exists . Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE get $/ -R -Vd7/30/2004;2:51P -Yccnet,ccnet -I-N at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) in d:\sourceforge\ccnet\pr oject\core\sourcecontrol\ProcessSourceControl.cs:line 59 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vss.GetSource(IntegrationResult result) in d:\sourceforge\ccnet\project\core\sou rcecontrol\Vss.cs:line 182 at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d: \sourceforge\ccnet\project\core\Project.cs:line 162 ---------- --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Matt P. <mpe...@re...> - 2004-07-27 20:04:30
|
The following is an enhancement to the Svn source control class to
allow the username and password which is used to connect to
svn as a configuration in the config file.
51,56d50
< [ReflectorProperty("username", Required = false)]
< public string Username;
<
< [ReflectorProperty("password", Required = false)]
< public string Password;
<
114,130c108
<
< System.Text.StringBuilder sb = new System.Text.StringBuilder();
< sb.Append(string.Format(HISTORY_COMMAND_FORMAT,
FormatCommandDate(from), FormatCommandDate(to), _trunkUrl));
<
< if (this.Username != null && this.Username.Trim().Length > 0)
< {
< sb.Append(" --username ");
< sb.Append(this.Username);
< }
<
< if (this.Password != null && this.Password.Trim().Length > 0)
< {
< sb.Append(" --password ");
< sb.Append(this.Password);
< }
<
< return sb.ToString();
---
> return string.Format(HISTORY_COMMAND_FORMAT,
FormatCommandDate(from), FormatCommandDate(to), _trunkUrl);
135,156c113,114
<
< System.Text.StringBuilder sb = new System.Text.StringBuilder();
< sb.Append(
< string.Format(
< TAG_COMMAND_FORMAT, label, _trunkUrl,
< this._tagBaseUrl + "/" + label
< )
< );
<
< if (this.Username != null && this.Username.Trim().Length > 0)
< {
< sb.Append(" --username ");
< sb.Append(this.Username);
< }
<
< if (this.Password != null && this.Password.Trim().Length > 0)
< {
< sb.Append(" --password ");
< sb.Append(this.Password);
< }
<
< return sb.ToString();
---
> string tagUrl = _tagBaseUrl + "/" + label;
> return string.Format(TAG_COMMAND_FORMAT, label, _trunkUrl, tagUrl);
|
|
From: Cromwell, R. F. <rcr...@ss...> - 2004-07-27 19:31:35
|
Be Careful with this. If you are using Terminal Services or Remote
Desktop and you close the desktop, not logoff, but close, Ctrl-C is sent
to each application. We ran into this with a poorly written console
application that was wrapped into an NT service. The console
application was listening for this and doing some clean up, but all of a
sudden our production server would just go loopy. It turned out that an
operations guy was opening a terminal session to the server and
disconnecting rather than logging off.
-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of
ji...@pu...
Sent: Tuesday, July 27, 2004 2:31 PM
To: ccn...@li...
Subject: [Ccnet-devel] [JIRA] Resolved: (CCNET-120) "port in use"
remoting exception
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Tue, 27 Jul 2004 11:30 AM
the remoting channels will now be explicitly unregistered when the ccnet
server shuts down. this should prevent the port from getting kept open
by cctray. in order to ensure that the ccnet console shuts down
gracefully, the CTRL-C keystroke is captured and the ccnet server is
properly disposed.
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-120
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-120
Summary: "port in use" remoting exception
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.7
Assignee: Owen Rogers
Reporter: Owen Rogers
Created: Mon, 28 Jun 2004 7:39 AM
Updated: Tue, 27 Jul 2004 11:30 AM
Description:
a number of people have reported experiencing receiving a "port in use"
remoting exception when restarting ccnet. the issue is that ccnet does
not properly unregister its remoted objects and close the channels at
shutdown. normally this is not a problem as the remoting system will
shutdown (closing all channels) after a period of time. however,
because most people are using cctray, cctray's polling behaviour keeps
remoting from closing the channels. this is why you receive the "port
in use" method when restarting ccnet. i'm currently working on a fix
that will make the server clean up properly. until then, if you are
experiencing this issue, please make sure that you shut down running
instances of cctray before restarting the server.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: <ji...@pu...> - 2004-07-27 18:42:32
|
The following issue has been updated:
Updater: Owen Rogers (mailto:or...@th...)
Date: Tue, 27 Jul 2004 11:39 AM
Changes:
timeestimate changed from 0 minutes
Fix Version changed to 0.7
Fix Version changed from 1.0
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.public.thoughtworks.org/browse/CCNET-45?page=history
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-45
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-45
Summary: CCNet console throws an exception when using -help flag
Type: Bug
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: 4 hours
Remaining: Unknown
Project: CruiseControl .NET
Components:
Console
Fix Fors:
0.7
Versions:
0.5
Assignee: Joachim Chapman
Reporter: Owen Rogers
Created: Tue, 13 Apr 2004 9:19 PM
Updated: Tue, 27 Jul 2004 11:39 AM
Description:
When executing ccnet.exe in a directory where there is no ccnet.config file, the console exe will throw an exception even if the -help flag is used. The order in which the -help flag is resolved needs to be fixed.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-27 18:40:29
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Tue, 27 Jul 2004 11:37 AM
uros novak has contributed a patch for this issue. it is now committed and built into ccnetlive build 0.6.0.326
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-16
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-16
Summary: Implement ModificationFilter SourceControl
Type: New Feature
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Fix Fors:
0.7
Versions:
0.5 (CCNetLive)
Assignee: Owen Rogers
Reporter: Owen Rogers
Created: Thu, 25 Mar 2004 6:06 AM
Updated: Tue, 27 Jul 2004 11:37 AM
Description:
>> I'd like to be so bold as to suggest a feature that I've been
>> thinking of for awhile.
>>
>> We have a pretty large project with loads of files in CVS.
>> We build with CCNet for .NET but with CC + Ant for Java. The
>> code resides in the same cvs module so any java check in will
>> trigger a client build and vice versa. The build put strain
>> on the machines and takes some time. We've had to reduce the
>> integration time to 1 hour because of it.
>>
>> I'd like to suggest that one can set the path(s) for which
>> a new build should be triggered. Maybe even specify file types.
>> E.g. if files in ...\sharpcode\* has changed, build, otherwise
>> skip the changes. Or, if *.cs;*.csproj files changes trigger
>> a build, otherwise not. Maybe even combination of excludes/includes
>> of files/folders.
>>
>> Anyone else feel that this would be useful?
pip's implementation recommendation:
This came up on the user list. I think a really nice way of implementing
this would be to write a 'ModificationFilter' class that implements
'ISourceControl', but decorates an underlying 'real' source control,
just like the 'MultiSourceControl' class does. It would delegate to the
underlying ISourceControl to get the full list of modifications, and
then run filters against the each modification's path.
To start with, it could just do simple single file excludes. I'm
thinking it may need a way of specifying what the base directory is for
some source controls (CVS wouldn't need this, but Perforce would since
it returns full depot paths for modification paths.)
Anyone fancy looking at this? Its a nice self-contained piece and would
be fairly easy for newbies to the project to work on.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-27 18:36:36
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Tue, 27 Jul 2004 11:33 AM
this bug was caused for the same reasons as the "port in use" issue: CCNET 120 -- which is now resolved.
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-94
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-94
Summary: CCNet server does not work with HttpChannel
Type: Bug
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Configuration
Fix Fors:
0.7
Versions:
0.6.1
Assignee:
Reporter:
Created: Fri, 21 May 2004 9:25 AM
Updated: Tue, 27 Jul 2004 11:33 AM
Description:
Mark Miller wrote:
If I change the channel type to http, I get an invalid cast in
VerifyCruiseManagerIsRemoted. If you have any advice, I'd love to
have those services available.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-27 18:33:29
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Tue, 27 Jul 2004 11:30 AM
the remoting channels will now be explicitly unregistered when the ccnet server shuts down. this should prevent the port from getting kept open by cctray. in order to ensure that the ccnet console shuts down gracefully, the CTRL-C keystroke is captured and the ccnet server is properly disposed.
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-120
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-120
Summary: "port in use" remoting exception
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.7
Assignee: Owen Rogers
Reporter: Owen Rogers
Created: Mon, 28 Jun 2004 7:39 AM
Updated: Tue, 27 Jul 2004 11:30 AM
Description:
a number of people have reported experiencing receiving a "port in use" remoting exception when restarting ccnet. the issue is that ccnet does not properly unregister its remoted objects and close the channels at shutdown. normally this is not a problem as the remoting system will shutdown (closing all channels) after a period of time. however, because most people are using cctray, cctray's polling behaviour keeps remoting from closing the channels. this is why you receive the "port in use" method when restarting ccnet. i'm currently working on a fix that will make the server clean up properly. until then, if you are experiencing this issue, please make sure that you shut down running instances of cctray before restarting the server.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-27 13:17:26
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-128 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-128 Summary: NUnit task should have configurable timeout Type: Improvement Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Builder Versions: 0.7 Assignee: Reporter: Created: Tue, 27 Jul 2004 6:14 AM Updated: Tue, 27 Jul 2004 6:14 AM Description: The NUnit task should have a configurable timeout property, just like the NAnt Builder. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <ji...@pu...> - 2004-07-27 10:10:30
|
The following comment has been added to this issue:
Author: Stephane Tombeur
Created: Tue, 27 Jul 2004 3:07 AM
Body:
Hi Owen,
I took the 0_6_0_323 build of ccnetlive and tried out the schedule-daily mechanism.
I think there might be a problem with the _integrationTime field. It's defined as a 'System.TimeSpan', but you expect the format to conform to ShortTimePattern. The way the field is used, I thought it would be better to make it of type 'System.DateTime'. In any case, with TimeSpan it doesn't work exactly how you expect it to, being that you fill in a time when integration should occur:
<schedule type="daily" integrationTime="12:00 AM"/> (this doesn't work)
My suggestion:
Either you continue to use a TimeSpan, but then the errormessage should be changed, or you change the property to be of type DateTime.
regards,
Stephane
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-79?page=comments#action_10335
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-79
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-79
Summary: Daily schedule doesn't work right
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Schedule
Fix Fors:
0.7
Versions:
0.6
Assignee:
Reporter:
Created: Fri, 7 May 2004 7:13 AM
Updated: Tue, 27 Jul 2004 3:07 AM
Description:
The daily schedule doesn't work properly. It doesn't set the next integration to be the next day after an integration ends. After the first integration time passes, it goes into a loop of constantly checking source control for modifications.
It also doesn't allow a forced build. Here is a modified version of DailySchedule.cs and ProjectIntegrator.cs that fixes these two issues. I added the lines delimited with
//**** below.
--- DailySchedule.cs: added 9 lines ---
using Exortech.NetReflector;
using System;
using System.Globalization;
using ThoughtWorks.CruiseControl.Core.Config;
using ThoughtWorks.CruiseControl.Remote;
namespace ThoughtWorks.CruiseControl.Core.Schedules
{
[ReflectorType("daily")]
public class DailySchedule : ISchedule
{
private TimeSpan _integrationTime;
private DateTime _nextIntegration;
//****
private bool _forceNextBuild = false;
//****
[ReflectorProperty("integrationTime")]
public string IntegrationTime
{
get { return _integrationTime.ToString(); }
set
{
try
{
_integrationTime = TimeSpan.Parse(value);
SetNextIntegration();
}
catch (Exception ex)
{
string msg = "Unable to parse daily schedule integration
time: {0}. The integration time should be specified in the format: {1}.";
throw new ConfigurationException(string.Format(msg,
value, CultureInfo.CurrentCulture.DateTimeFormat.ShortTimePattern), ex);
}
}
}
private void SetNextIntegration()
{
DateTime now = Now;
_nextIntegration = new DateTime(now.Year, now.Month, now.Day, _integrationTime.Hours, _integrationTime.Minutes, 0, 0);
}
public bool ShouldStopIntegration()
{
return false;
}
public void ForceBuild()
{
//****
_forceNextBuild = true;
//****
}
public void IntegrationCompleted()
{
//****
DateTime now = Now;
_nextIntegration = new DateTime(now.Year, now.Month, now.Day+1, _integrationTime.Hours, _integrationTime.Minutes, 0, 0);
//****
}
public BuildCondition ShouldRunIntegration()
{
//****
if (_forceNextBuild)
{
_forceNextBuild = false;
return BuildCondition.ForceBuild;
}
//****
if (Now > _nextIntegration)
{
return BuildCondition.IfModificationExists;
}
return BuildCondition.NoBuild;
}
protected virtual DateTime Now
{
get { return DateTime.Now; }
}
}
}
--- ProjectIntegrator.cs replaced 1 line ---
In ProjectIntegrator.cs you could change ForceBuild() to use reflection to avoid the casting exception at line 86 (error checking could be improved).
public void ForceBuild()
{
Log.Info("Force Build for project: " + _project.Name);
Start();
// ((Schedules.Schedule)_schedule).ForceBuild(); // Replace this
line with the following:
//****
_schedule.GetType().InvokeMember("ForceBuild",
System.Reflection.BindingFlags.InvokeMethod, null, _schedule, null);
//****
}
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: Mike R. <mik...@th...> - 2004-07-27 09:54:12
|
I talked to Owen last night, and we decided to add backwards compatibility for this change since it was easy to do so. Build 324 and onwards will rename your ccnet.state file for you, so you don't need to worry. On a slightly different point, if you *are* using a multi-project server and therefore have <state> tags in your config file, you can rename your specified state files as described below and then remove your <state> tags if you now want to let CCNet handle state file names for you. Mike Mike Roberts wrote: > Hi all, > > I have made a change in CCNetLive build 323 that may require you to > manually update your system. > > If you do not manually specify a 'state' file in your ccnet.config > file, build 323 and later will try and use a different file to store > the state of the build. If you upgrade from a build before 323 then > without any work on your part CCNet will ignore your state file, and > start using a new one. This means that your build number will be reset > and CCNet will look at all changes in the last 24 hours for the last > build. > > To work around this, you have the following 2 options: > - Let CCNet perform its first build and then stop it. Locate the new > state file, copy its name, delete it then rename your old state file > (ccnet.state) as the new one. Restart CCNet and it will rebuild from > your old, but renamed, state file. > - If this extra build is a problem, you'll need to stop CCNet and > rename your state file anyway. The name will reflect the 'Camel Case' > name of your project. That means that if your project is called 'my > project' then the new state file will be called 'MyProject.state'. > - If you manually specify the name of your state file in a <state> > section, you won't be effected. > > This change was made to implement issue CCNet-107. Multi-project > instances of CCNet now work without you having to specify the names of > your state files. > > If you have any questions about this change, please ask. > > Mike > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Ccnet-user mailing list > Ccn...@li... > https://lists.sourceforge.net/lists/listinfo/ccnet-user |
|
From: <ji...@pu...> - 2004-07-27 09:48:26
|
The following comment has been added to this issue:
Author:
Created: Tue, 27 Jul 2004 2:45 AM
Body:
Breaking change is fixed in build 324 (backwards compatibility now works through renaming old file)
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-107?page=comments#action_10334
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-107
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-107
Summary: Project name should be included in the state file name
Type: Improvement
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.7
Assignee:
Reporter: Owen Rogers
Created: Sun, 13 Jun 2004 10:25 AM
Updated: Tue, 27 Jul 2004 2:45 AM
Description:
by default, the state filename should include the project name so that it doesn't cause conflicts when multiple projects are used.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-27 08:32:26
|
The following comment has been added to this issue:
Author: Stephane Tombeur
Created: Tue, 27 Jul 2004 1:29 AM
Body:
I've created an MSBuild plugin. It's basically the same as the NAntBuilder, but with a few tweaks to the arguments. It works for the Visual Studio 2005 Beta 1 release of MSBuild. (v2.0.40607).
It might be necessary to add a <supportedruntime/> tag with the above versionnumber to ccnet.exe.config (not sure about that).
------- start of MSBuilder.cs ---------
using Exortech.NetReflector;
using System;
using System.Threading;
using System.IO;
using ThoughtWorks.CruiseControl.Core.Config;
using ThoughtWorks.CruiseControl.Core.Util;
using ThoughtWorks.CruiseControl.Remote;
using System.Text;
namespace ThoughtWorks.CruiseControl.Core.Builder
{
[ReflectorType("msbuild")]
public class MSBuilder : IBuilder
{
public const int DEFAULT_BUILD_TIMEOUT = 600;
public const string DEFAULT_EXECUTABLE = "msbuild.exe";
public const string DEFAULT_BASEDIRECTORY = ".";
public const string DEFAULT_LABEL = "NO-LABEL";
private ProcessExecutor _executor;
public MSBuilder() : this(new ProcessExecutor()) { }
public MSBuilder(ProcessExecutor executor)
{
_executor = executor;
}
[ReflectorProperty("executable", Required = false)]
public string Executable = DEFAULT_EXECUTABLE;
[ReflectorProperty("baseDirectory", Required = false)]
public string BaseDirectory = DEFAULT_BASEDIRECTORY;
[ReflectorProperty("buildFile", Required = false)]
public string BuildFile;
[ReflectorProperty("buildArgs", Required = false)]
public string BuildArgs;
[ReflectorArray("loggerList", Required = false)]
public string[] Loggers = new string[0];
[ReflectorArray("targetList", Required = false)]
public string[] Targets = new string[0];
/// <summary>
/// Gets and sets the maximum number of seconds that the build may take. If the build process takes longer than
/// this period, it will be killed. Specify this value as zero to disable process timeouts.
/// </summary>
[ReflectorProperty("buildTimeoutSeconds", Required = false)]
public int BuildTimeoutSeconds = DEFAULT_BUILD_TIMEOUT;
/// <summary>
/// Runs the integration using MSBuild. The build number is provided for labelling, build
/// timeouts are enforced. The specified targets are used for the specified MSBuild build file.
/// StdOut from msbuild.exe is redirected and stored.
/// </summary>
/// <param name="result">For storing build output.</param>
public void Run(IntegrationResult result)
{
ProcessResult processResult = AttemptExecute(CreateProcessInfo(result));
result.Output = processResult.StandardOutput;
if (processResult.TimedOut)
{
throw new BuilderException(this, "MSBuild process timed out (after " + BuildTimeoutSeconds + " seconds)");
}
if (processResult.ExitCode == 0)
{
result.Status = IntegrationStatus.Success;
}
else
{
result.Status = IntegrationStatus.Failure;
Log.Info("MSBuild build failed: " + processResult.StandardError);
}
}
private ProcessInfo CreateProcessInfo(IntegrationResult result)
{
ProcessInfo info = new ProcessInfo(Executable, CreateArgs(result), BaseDirectory);
info.TimeOut = BuildTimeoutSeconds*1000;
return info;
}
protected ProcessResult AttemptExecute(ProcessInfo info)
{
try
{
return _executor.Execute(info);
}
catch (Exception e)
{
throw new BuilderException(this, string.Format("Unable to execute: {0}\n{1}", BuildCommand, e), e);
}
}
private string BuildCommand
{
get { return string.Format("{0} {1}", Executable, BuildArgs); }
}
/// <summary>
/// Creates the command line arguments to the nant.exe executable. These arguments
/// specify the build-file name, the targets to build to,
/// </summary>
/// <returns></returns>
internal string CreateArgs(IntegrationResult result)
{
return string.Format("{0} {1} {2} {3} {4}", CreateBuildFileArg(), CreateLoggersArg(), BuildArgs, CreateLabelToApplyArg(result), CreateTargetsArg()).Trim();
}
private string CreateBuildFileArg()
{
if (StringUtil.IsBlank(BuildFile)) return string.Empty;
//return "-buildfile:" + BuildFile;
return BuildFile;
}
private string CreateLoggersArg()
{
if (Loggers.Length == 0) return string.Empty;
return string.Join(" /logger:", Loggers);
}
private string CreateTargetsArg()
{
if (Targets.Length == 0) return string.Empty;
return "/target:" + string.Join(";", Targets);
}
private string CreateLabelToApplyArg(IntegrationResult result)
{
string label = StringUtil.IsBlank(result.Label) ? DEFAULT_LABEL : result.Label;
return "/property:label-to-apply=" + label;
}
public bool ShouldRun(IntegrationResult result)
{
return result.Working && result.HasModifications();
}
public override string ToString()
{
return string.Format(@" BaseDirectory: {0}, Targets: {1}, Executable: {2}, BuildFile: {3}", BaseDirectory, CreateTargetsArg(), Executable, BuildFile);
}
}
}
----- end of MSBuilder.cs ------
the build node in the config file looks like this:
-----
<build type="msbuild">
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\MSBuild.exe</executable>
<baseDirectory>d:\temp\MyProject</baseDirectory>
<buildArgs>@buildfile.response</buildArgs>
<buildFile>MyProject.sln</buildFile>
<targetList>
<target>All</target>
</targetList>
<!-- loggerList is untested, as I don't have any MSBuild loggers yet,
see the 3 msbuild articles on MSDN for more info on loggers -->
<loggerList>
<logger>SolutionLogger,ACMELogger;file="Build.txt";verbose=true</logger>
</loggerList>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
</build>
-----
All that remains to be done is to create a NAnt-like xml logger for msbuild so that build output can be merged with ccnet build logs.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-20?page=comments#action_10333
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-20
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-20
Summary: Support for MSBuild
Type: New Feature
Status: Open
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Builder
Fix Fors:
1.0
Versions:
0.5
Assignee: Owen Rogers
Reporter: Mike Roberts
Created: Tue, 30 Mar 2004 12:59 AM
Updated: Tue, 27 Jul 2004 1:29 AM
Description:
We need an MSBuild Build plugin.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: Mike R. <mik...@th...> - 2004-07-26 17:27:49
|
Hi all, I have made a change in CCNetLive build 323 that may require you to manually update your system. If you do not manually specify a 'state' file in your ccnet.config file, build 323 and later will try and use a different file to store the state of the build. If you upgrade from a build before 323 then without any work on your part CCNet will ignore your state file, and start using a new one. This means that your build number will be reset and CCNet will look at all changes in the last 24 hours for the last build. To work around this, you have the following 2 options: - Let CCNet perform its first build and then stop it. Locate the new state file, copy its name, delete it then rename your old state file (ccnet.state) as the new one. Restart CCNet and it will rebuild from your old, but renamed, state file. - If this extra build is a problem, you'll need to stop CCNet and rename your state file anyway. The name will reflect the 'Camel Case' name of your project. That means that if your project is called 'my project' then the new state file will be called 'MyProject.state'. - If you manually specify the name of your state file in a <state> section, you won't be effected. This change was made to implement issue CCNet-107. Multi-project instances of CCNet now work without you having to specify the names of your state files. If you have any questions about this change, please ask. Mike |
|
From: <ji...@pu...> - 2004-07-26 16:12:27
|
Message:
The following issue has been resolved as FIXED.
Resolver: Mike Roberts
Date: Mon, 26 Jul 2004 9:08 AM
This is fixed in build 323.
NB - This is a *breaking change* for people who don't specify state files explicitly since the state file name now always reflects the project name
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-107
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-107
Summary: Project name should be included in the state file name
Type: Improvement
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.7
Assignee:
Reporter: Owen Rogers
Created: Sun, 13 Jun 2004 10:25 AM
Updated: Mon, 26 Jul 2004 9:08 AM
Description:
by default, the state filename should include the project name so that it doesn't cause conflicts when multiple projects are used.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-23 19:41:22
|
The following comment has been added to this issue:
Author:
Created: Fri, 23 Jul 2004 12:38 PM
Body:
I don't know if it's related or not, but there appear to be thread-safety defects in nant's XmlLogger that only show up on multiprocessor machines. We've reported this to the nant folks.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-105?page=comments#action_10322
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-105
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-105
Summary: Building CCNET fails unit test on multi-processor machine
Type: Bug
Status: Open
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Versions:
0.6
0.6.1
Assignee: Owen Rogers
Reporter:
Created: Thu, 10 Jun 2004 11:17 AM
Updated: Fri, 23 Jul 2004 12:38 PM
Environment: WindowsXP SP1 Dual Xeon 2.4GHz, 1.00GB RAM
Description:
When building the cruise control source (using b.bat), the build fails in the ForceBuild test with a ThreadStateException. If I set my machine to use only a single processor (through the BIOS), the build works.
The build log follows:
NAnt 0.85 (Build 0.85.1591.0; net-1.1.win32; nightly; 5/10/2004)
Copyright (C) 2001-2004 Gerry Shaw
NAnt Team
Buildfile: file:///G:/DOWNLO~1/tools/CONTIN~1/CC.NET/CRUISE~4.SOU/ccnet.build
Target(s) specified: test
init:
[mkdir] Creating directory 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build'.
compile:
[solution] Starting solution build.
[solution] Skipping 'Shared' [build]...
[solution] Building 'Remote' [build]...
[solution] Building 'WebService' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebService\..\..\build\webservice\'.
[solution] Building 'XMLRPCWebService' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\XMLRPCWebService\..\..\build\XMLRPCWebService\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\XMLRPCWebService\..\..\build\XMLRPCWebService\'.
[solution] Building 'WebServiceProxy' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebServiceProxy\..\..\build\webserviceproxy\'.
[solution] Building 'CCTray' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
[copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
[solution] Building 'core' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\publishers\BuildLogTransformer.cs(54,24): warning CS0618: 'System.Xml.Xsl.XslTransform.Transform(System.Xml.XPath.IXPathNavigable, System.Xml.Xsl.XsltArgumentList)' is obsolete: 'You should pass XmlResolver to Transform() method'
[solution] Building 'WebDashboard' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
[copy] Copying 4 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
[solution] Building 'web' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
[copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\web\LogTransformer.cs(34,36): warning CS0618: 'System.Xml.Xsl.XslTransform.Transform(System.Xml.XPath.IXPathNavigable, System.Xml.Xsl.XsltArgumentList)' is obsolete: 'You should pass XmlResolver to Transform() method'
[solution] Building 'service' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
[copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
[solution] Building 'console' [build]...
[copy] Copying 6 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\console\..\..\build\server\'.
[solution] Building 'ControlPanel' [build]...
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
[copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
[copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\server\ccnet.exe.config'.
[copy] Copying 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\console\app.config' to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\server\ccnet.exe.config'.
[copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\service\ccservice.exe.config'.
[copy] Copying 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\app.config' to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\service\ccservice.exe.config'.
test.unit:
[exec] G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\tools\nunit\nunit-console.exe ThoughtWorks.CruiseControl.Core.dll /xml:../ThoughtWorks.CruiseControl.Core.dll-results.xml /nologo
.N.................................................................N......................................................................................................................................................................................F...............................................N.................................................................................................................................
Tests run: 421, Failures: 1, Not run: 3, Time: 17.2497792 seconds
Failures:
1) ThoughtWorks.CruiseControl.Core.Test.ProjectIntegratorTest.ForceBuild : System.Threading.ThreadStateException : Thread is running or terminated; it can not restart.
at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)
at System.Threading.Thread.Start()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Start() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\ProjectIntegrator.cs:line 74
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.ForceBuild() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\ProjectIntegrator.cs:line 84
at ThoughtWorks.CruiseControl.Core.Test.ProjectIntegratorTest.ForceBuild() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\test\ProjectIntegratorTest.cs:line 234
Tests not run:
1) ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.StarTeamHistoryParserTest.TestNothing : This is an incomplete test
2) ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.VaultTest.HistoryDates : user-specific vault test settings here
3) ThoughtWorks.CruiseControl.Core.Publishers.Test.NetSendPublisherTest.Send : move to acceptance tests
BUILD FAILED
G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\ccnet.build(52,4):
External Program Failed: G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\tools\nunit\nunit-console.exe (return code was 1)
Total time: 28.3 seconds.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-23 14:29:23
|
The following comment has been added to this issue:
Author:
Created: Fri, 23 Jul 2004 7:26 AM
Body:
Sorry please remove this issue, it turns out it was a an smtp server issue after all.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-124?page=comments#action_10321
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-124
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-124
Summary: email publishers don't work consistently.
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Service
Versions:
0.6.1
Assignee:
Reporter:
Created: Wed, 21 Jul 2004 9:42 AM
Updated: Fri, 23 Jul 2004 7:26 AM
Environment: windows 2003 server, latest nightly
Description:
email publisher seems broken. Works when build fails, but not otherwise. Here is the exception in the ccnet.log I get when it doesn't send out emails.
7/21/2004 11:52:37 AM: [Integration:Warning]: Exception: Exception thrown by publisher
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publisher ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: EmailPublisher exception: System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.
--- End of inner exception stack trace ---
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
--- End of inner exception stack trace ---
at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
at System.Web.Mail.SmtpMail.Send(MailMessage message)
at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140 ---> System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.
--- End of inner exception stack trace ---
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
--- End of inner exception stack trace ---
at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
at System.Web.Mail.SmtpMail.Send(MailMessage message)
at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140
--- End of inner exception stack trace ---
at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 144
at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrationResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 127
at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_IntegrationCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\ccnet\project\core\publishers\PublisherBase.cs:line 38
--- End of inner exception stack trace ---
----------
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: Mike R. <mi...@tm...> - 2004-07-23 07:44:43
|
Hi there, I just wanted to give a 'heads up' to anyone using builds of CCNet from CCNetLive. I'm currently in the middle of a major update to the 'Dashboard' application that will implement the multi-project / multi-server / minimal-configuration / combined dashboard and project reporter functionality that we've wanted for a while. I've checked some changes in, but please bare in mind that before its a bit more complete than it currently is that the Dashboard should be considered 'unstable'. That said, I will endeavour to keep a working build at all times. This work has required updates to the server's remote interface so if you do use new builds, you may need to update your CCTray application too. I hope to get this work to a level of stability over the next week or so. Once it is, I'll get it up and working on CCNetLive and let you all know. Cheers, Mike |
|
From: <ji...@pu...> - 2004-07-22 14:32:29
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-127 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-127 Summary: CCTray uses 21 mb memory Type: Improvement Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: CCTray Versions: 0.6.1 Assignee: Reporter: Created: Thu, 22 Jul 2004 7:29 AM Updated: Thu, 22 Jul 2004 7:29 AM Environment: OS: Windows XP Description: On my development environment CCTray uses 21 mb of memory. It connects to a CC server on which four projects are configured. CCTray is configured to Poll every 60 seconds. Show balloon Notifications and Show exceptions are on. No of the agents are configured, but all four audio events are enabled. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <ji...@pu...> - 2004-07-22 12:44:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-126 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-126 Summary: Reasons for build failure not reported when nant called twice Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Versions: 0.6.1 Assignee: Reporter: Sam Mackrill Created: Thu, 22 Jul 2004 5:41 AM Updated: Thu, 22 Jul 2004 5:41 AM Environment: Win2003 Server, nant 0.84, nunit 2.1.4 Description: My bootstrap (see below) is calling nant twice. If the second call (kit) fails then the build is reported as failed but no reasons are given. <?xml version="1.0"?> <project name="LogProcessor-bootstrap" default="go"> <property name="target" value="test" /> <property name="backup.file" value="e:\subversion\backups\done\backup\date.txt" /> <property name="daily.file" value="e:\subversion\Backups\done\dailybuild\date.txt" /> <property name="daily.flag" value="false" /> <property name="svn.user" value="cruisecontrol" /> <property name="svn.pwd" value="sittom" /> <target name="go" depends="bootstrap, dailycheck, build"/> <target name="bootstrap"> <exec basedir="." program="${svn.executable}" commandline="--username ${svn.user} --password ${svn.pwd} update" /> </target> <target name="build"> <echo message="target=${target}" /> <nant basedir="." buildfile="LogProcessor.build" target="${target}" inheritall="true" /> <if propertytrue="daily.flag"> <nant basedir="." buildfile="LogProcessor.build" target="kit" inheritall="true" /> <touch file="${daily.file}" /> </if> </target> <target name="dailycheck"> <if uptodatefile="${backup.file}" comparefile="${daily.file}"> <exec basedir="..\LogProcessorAcceptanceTests" program="${svn.executable}" commandline="--username ${svn.user} --password ${svn.pwd} update" /> <property name="target" value="daily" /> <property name="daily.flag" value="true" /> </if> </target> </project> --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <ji...@pu...> - 2004-07-22 12:37:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-125 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-125 Summary: Multi sourcecontrol causes exception in publisher Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Publisher Versions: 0.6.1 Assignee: Reporter: Sam Mackrill Created: Thu, 22 Jul 2004 5:34 AM Updated: Thu, 22 Jul 2004 5:34 AM Environment: Win2003 Server, Nant Build 0.84.1455.0, NUnit 2.1.4 Description: using this: <sourcecontrol type="multi"> <sourceControls> <svn> <executable>c:\program files\subversion\bin\svn.exe</executable> <trunkUrl>svn://svn.clickstream.net/LogProcessor/trunk</trunkUrl> </svn> <filesystem> <repositoryRoot>e:\subversion\backups\done\backup</repositoryRoot> </filesystem> </sourceControls> </sourcecontrol> I see the following in the ccnet console output when a file in the backup directory changes: [LogProcessor:Info]: No modifications detected. [LogProcessor:Info]: 1 modification detected. [LogProcessor:Info]: Building [LogProcessor:Info]: NAnt build failed: [LogProcessor:Info]: Build complete: Failure [LogProcessor:Info]: Integration complete: 22/07/2004 13:24:37 [LogProcessor:Warning]: Exception: Exception thrown by publisher ---------- ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publ isher ---> System.ArgumentNullException: Key cannot be null. Parameter name: key at System.Collections.Hashtable.get_Item(Object key) at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.GetEmailUser(Str ing username) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs: line 108 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.CreateModifiersL ist(Modification[] modifications) in d:\sourceforge\ccnet\project\core\publisher s\EmailPublisher.cs:line 193 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.CreateRecipientL ist(IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\Em ailPublisher.cs:line 183 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrati onResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\pr oject\core\publishers\EmailPublisher.cs:line 121 at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_Integrati onCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\cc net\project\core\publishers\PublisherBase.cs:line 38 --- End of inner exception stack trace --- ---------- Here is my publisher config: <publishers> <xmllogger> <logDir>..\web\log\LogProcessor</logDir> </xmllogger> <email from="bui...@cl..." mailhost="smtp.clickstream.com" includeDetails="TRUE"> <projectUrl>http://bob/CruiseControl</projectUrl> <users> <user name="Sam" group="developers" address="si...@cl..."/> </users> <groups> <group name="developers" notification="change"/> </groups> </email> </publishers> If I force the build manually or it triggers from subversion then everything seems fine. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <ji...@pu...> - 2004-07-22 12:10:28
|
The following comment has been added to this issue:
Author: Sam Mackrill
Created: Thu, 22 Jul 2004 5:06 AM
Body:
I have exactly this issue too.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-122?page=comments#action_10312
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-122
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-122
Summary: Timed out builds repeat indefinitely
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Builder
Versions:
0.6.1
Assignee:
Reporter:
Created: Fri, 16 Jul 2004 8:24 PM
Updated: Thu, 22 Jul 2004 5:06 AM
Environment: Windows Server 2003, Subversion 1.0.5, NAnt 0.84.1455.0, .NET 1.1
Description:
We have set a build timeout of 20 minutes, and one of the unit tests we've added has caused us to go over the 20 minute time limit. In the process, we uncovered a bug that appears to be new since we upgraded to 0.6.1 (from 0.4.2, I believe).
When a build times out, the system forgets that it's tried to do the build, and continues to do it indefinitely. For example, this is what our log looks like:
[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Warning]: Process timed out: C:\Working\head\3rdParty\NAnt\nant.exe -buildfile:bootstrap.nant -logger:NAnt.Core.XmlLogger -D:sccs=C:\Subversion\bin\svn.exe -D:label-to-apply=247 go. Process id: 3948
[head:Warning]: The timed out process has been killed: 3948
[head:Error]: Exception: NAnt process timed out (after 1200 seconds)
----------
ThoughtWorks.CruiseControl.Core.Builder.BuilderException: NAnt process timed out (after 1200 seconds)
at ThoughtWorks.CruiseControl.Core.Builder.NAntBuilder.Run(IntegrationResult result) in d:\sourceforge\ccnet\project\core\builder\NAntBuilder.cs:line 68
at ThoughtWorks.CruiseControl.Core.Project.RunBuild(IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 203
at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 163 BaseDirectory: C:\Working\head, Targets: go, Executable: C:\Working\head\3rdParty\NAnt\nant.exe, BuildFile: bootstrap.nant
----------
[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Warning]: Process timed out: C:\Working\head\3rdParty\NAnt\nant.exe -buildfile:bootstrap.nant -logger:NAnt.Core.XmlLogger -D:sccs=C:\Subversion\bin\svn.exe -D:label-to-apply=247 go. Process id: 5028
[head:Warning]: The timed out process has been killed: 5028
[head:Error]: Exception: NAnt process timed out (after 1200 seconds)
----------
ThoughtWorks.CruiseControl.Core.Builder.BuilderException: NAnt process timed out (after 1200 seconds)
at ThoughtWorks.CruiseControl.Core.Builder.NAntBuilder.Run(IntegrationResult result) in d:\sourceforge\ccnet\project\core\builder\NAntBuilder.cs:line 68
at ThoughtWorks.CruiseControl.Core.Project.RunBuild(IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 203
at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 163 BaseDirectory: C:\Working\head, Targets: go, Executable: C:\Working\head\3rdParty\NAnt\nant.exe, BuildFile: bootstrap.nant
----------
This continues on forever.
The work around is that we have to open up Task Manager and kill the NAnt process during one of these builds. The system then calls this a build failure, and goes on its merry way:
[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Info]: NAnt build failed:
[head:Info]: Build complete: Failure
[head:Info]: Integration complete: 7/16/2004 8:59:48 PM
[head:Info]: No modifications detected.
Definitely, we've had issues in the past where our builds would time out, and the system handled it gracefully in the past.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.public.thoughtworks.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <ji...@pu...> - 2004-07-21 16:46:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-124 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-124 Summary: email publishers don't work consistently. Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Service Versions: 0.6.1 Assignee: Reporter: Created: Wed, 21 Jul 2004 9:42 AM Updated: Wed, 21 Jul 2004 9:42 AM Environment: windows 2003 server, latest nightly Description: email publisher seems broken. Works when build fails, but not otherwise. Here is the exception in the ccnet.log I get when it doesn't send out emails. 7/21/2004 11:52:37 AM: [Integration:Warning]: Exception: Exception thrown by publisher ---------- ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publisher ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: EmailPublisher exception: System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140 ---> System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140 --- End of inner exception stack trace --- at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 144 at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrationResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 127 at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_IntegrationCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\ccnet\project\core\publishers\PublisherBase.cs:line 38 --- End of inner exception stack trace --- ---------- --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: Martin A. <mar...@go...> - 2004-07-21 11:44:33
|
This one as well becouse of Datetime formatting:
I'm not sure which is correct, since "30 Aug" is under english and "30 =
VIII" under mine (czech) culture setting.
Failures:
1) =
ThoughtWorks.CruiseControl.Web.Test.LogFileListTest.GetLinks :
String lengths differ. Expected length=3D34, but was =
length=3D35.
Strings differ at index 9.
expected:<"<nobr>30 Aug 2002 16:40 (6)</nobr>">
but was:<"<nobr>30 VIII 2002 16:40 (6)</nobr>">
-------------------^
at =
ThoughtWorks.CruiseControl.Web.Test.LogFileListTest.GetLinks()
in e:\src\extern\ccnet\project\web\test\LogFileListTest.cs:line 54
Regards,
Martin |
|
From: Martin A. <mar...@go...> - 2004-07-21 11:31:24
|
Second test-case which is failing for me:
[Test]
public void StartProcessRunningCmdExeCallingNonExistentFile()
{
ProcessResult result =3D executor.Execute(new ProcessInfo("cmd.exe", =
"/C @zerk.exe foo"));
AssertProcessExitsWithFailure(result, 1);
AssertEquals(@"'zerk.exe' is not recognized as an internal or =
external command,
operable program or batch file.", result.StandardError.Trim());
AssertEquals(string.Empty, result.StandardOutput);
Assert("process should not have timed out", ! result.TimedOut);
}
I dont think it is good idea to compare cmd.exe output to fixed string =
since it could vary from system to system or even between windows =
language versions. Moreover win9x/ME do not have cmd.exe at all. What =
about removing this test (it do not test anything important, does it?)
Regards,
Martin |
|
From: Martin A. <mar...@go...> - 2004-07-21 11:21:38
|
Hello,
Now I'm trying to build ccnet from sources. I builds fine but some tests =
are failing.
First CanCreateHistoryProcess in =
core\sourcecontrol\test\ClearCaseTest.cs. Datetime.Parse is not correct =
under non-english environment. I fixed it to:
System.IFormatProvider format =3D =
System.Globalization.CultureInfo.InvariantCulture;
ProcessInfo processInfo =3D _clearCase.CreateHistoryProcessInfo( =
DateTime.Parse(since,format), DateTime.Now );
But even now it fails becouse of bug in the implementation itself IMO =
(assertion error):
1) =
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.ClearCaseTest.CanCreat=
eHistoryProcess :
String lengths differ. Expected length=3D138, but was =
length=3D137.
Strings differ at index 27.
expected:<"lshist -r -nco -since 02-Feb-2002.05:00:00 =
-fmt "%u#~#%Vd#~#...">
but was:<"lshist -r -nco -since 02-II-2002.05:00:00 -fmt =
"%u#~#%Vd#~#%...">
-------------------------------------^
Looks like invalid datetime formatting again.
Regards,
Martin |