Menu
▾
▴
ccnet-devel — Development List
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) |
2
(1) |
3
|
4
(2) |
5
|
|
6
|
7
(2) |
8
(2) |
9
(4) |
10
(1) |
11
|
12
|
|
13
(9) |
14
(5) |
15
(12) |
16
(4) |
17
(6) |
18
(2) |
19
|
|
20
|
21
(4) |
22
(4) |
23
(3) |
24
(2) |
25
(2) |
26
(1) |
|
27
(7) |
28
(4) |
29
(2) |
30
(2) |
|
|
|
|
From: McCullough, G. <gar...@CH...> - 2004-06-30 15:31:31
|
I wanted to use ccnet to kick off certain tasks at regular intervals regardless of whether there are changes in source files. To accomplish I created a new custom scheduler class called IntervalScheduler. =20 A few things came up in doing this that I thought I'd point out: =20 1. There is an ISchedule interface but it isn't enough to implement that interface. You get a runtime error when ccnet attempts to cast your scheduler to the Schedule class type. This strikes me as a mistake. Either it should be enough to implement the interface or else you should be required to use a specific scheduler base class. To workaround the problem above, I inherited my new scheduler from the Schedule class. But this is not a great solution because the Schedule class does a lot of stuff I didn't care about in my Interval scheduler. =20 2. I discovered that the Schedule class won't execute any intervals longer than 59 seconds. The reason for this is that elapsed time is checked against a TimeSpan object's Seconds property. But I think what you really want there is TimeSpan.TotalSeconds. TotalSeconds gives the total # of seconds elapsed in the timespan, whereas the Seconds property gives only the number of seconds of the elapsed days, hours, & minutes. In other words, Seconds is never greater than 59. =20 _____ =20 Gary McCullough=20 =20 |
|
From: <ji...@pu...> - 2004-06-30 06:52:21
|
The following comment has been added to this issue:
Author:
Created: Tue, 29 Jun 2004 11:49 PM
Body:
We had similar problem with the code in Draco.net with the Visual
SourceSafe date ranges.
The VSS documentation suggests always using American date format
with a two digit year and outputting the time in hh:mm[a|p] format,
however that does not work correctly with changes to time / date format.
Based on experimentation Sourcesafe responds to the regional settings for ShortDateFormat and those for *Long* time. However, Sourcesafe appears to do some very unusual manipulations to arrive at a time format using the long time format. It seems use information from the longtimeformat for the cultureinfo (and disregard shorttimeformat altogether) but it does some weird things.
1) takes the first hour indicator in the long time format and uses
that, but disregards if it is double or single:
HH:mm:ss => H
hh:mm:ss => h
or other wacky combos like ss---mm---hh---HH => h
single letter of the first H or h encountered
2) uses the time separator as supplied by culture info
3) then always puts "mm" after that even if minutes were specified
to "m" in the long time format
4) if it is "h" for hour then it puts "t" at the end (am/pm)
So there are really only two time formats that ss.exe is making use
of:
h[separator]mmt
or
H[separator]mm
based on whichever H or h is first encountered in the LongTimeFormat
for the CultureInfo.
We ended up with code like this to determine the date-time format string appropriate for Visual Sourcesafe:
private static string SetupVssDateTimeFormat() {
DateTimeFormatInfo dateTimeFormat =
CultureInfo.CurrentCulture.DateTimeFormat;
string vssFormat24hr = String.Format("{0};HH{1}mm",
dateTimeFormat.ShortDatePattern,
dateTimeFormat.TimeSeparator);
string vssFormat12hr = String.Format("{0};h{1}mmt",
dateTimeFormat.ShortDatePattern,
dateTimeFormat.TimeSeparator);
int posCapitalH = dateTimeFormat.LongTimePattern.IndexOf("H");
bool capitalHPresent = posCapitalH >= 0;
int posLowerH = dateTimeFormat.LongTimePattern.IndexOf("h");
bool lowerHPresent = posLowerH >=0;
// Default to 24hr format
string format = vssFormat24hr;
if ( lowerHPresent ) {
if ( !capitalHPresent || posLowerH < posCapitalH ) {
format = vssFormat12hr;
}
}
return format;
}
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-111?page=comments#action_10258
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-111
Summary: Checking for new versions in Visual Sourcesafe runs 12 hours behind
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Versions:
0.6
Assignee:
Reporter:
Created: Tue, 15 Jun 2004 5:56 AM
Updated: Tue, 29 Jun 2004 11:49 PM
Environment: Windows XP, Visual SourceSafe 6.0d, .NET Framework 1.1, CruiseControl .NET 0.6
Description:
We use Visual SourceSafe 6.0d as Source Control component in our project. When CruiseControl .NET searches for newer versions in SourceSafe, the -v argument of the getHistory method of SourceControl is invalid.
The -v arugment (version argument) requires a start and an end time. But the end-time isn't aware of AM or PM. Run CruiseControl.NET in the morning (at 10AM) and everything will work. But when you run this at 3PM in the afternoon, the arguments will be (last-build-time)-3:00:00. He thinks that 3:00PM is the same as 3:00AM.
---------------------------------------------------------------------
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-06-29 21:33:22
|
The following comment has been added to this issue:
Author: James Hebben
Created: Tue, 29 Jun 2004 2:30 PM
Body:
We saw this problem also. It seems to be a bug in SourceSafe rather than CC.NET. The docs state that you should be able to specify 12 hour clock times, but it simply does not work. We replicated this bug in the source safe explorer history dialog. Entering times using a 24 hour clock works fine.
We changed the build computer so that the system time uses a 24 hour clock (Control Panel | Regional Settings | Customize | Time | Time format=HH:mm:ss). Everything works fine.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-111?page=comments#action_10257
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-111
Summary: Checking for new versions in Visual Sourcesafe runs 12 hours behind
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Versions:
0.6
Assignee:
Reporter:
Created: Tue, 15 Jun 2004 5:56 AM
Updated: Tue, 29 Jun 2004 2:30 PM
Environment: Windows XP, Visual SourceSafe 6.0d, .NET Framework 1.1, CruiseControl .NET 0.6
Description:
We use Visual SourceSafe 6.0d as Source Control component in our project. When CruiseControl .NET searches for newer versions in SourceSafe, the -v argument of the getHistory method of SourceControl is invalid.
The -v arugment (version argument) requires a start and an end time. But the end-time isn't aware of AM or PM. Run CruiseControl.NET in the morning (at 10AM) and everything will work. But when you run this at 3PM in the afternoon, the arguments will be (last-build-time)-3:00:00. He thinks that 3:00PM is the same as 3:00AM.
---------------------------------------------------------------------
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: Chris B. <CB...@th...> - 2004-06-29 01:27:26
|
SGkgR3V5cywNCg0KTm8gSSBkaWRuJ3QgZml4IDkyPw0KDQpJIG1hZGUgYSBjaGFuZ2Ugc28gdGhh dCB3aGVuIGEgY29ubmVjdGlvbiBpcyBsb3N0IGl0IHdpbGwgYXBwZWFyIGluIHRoZSANCmJhbGxv b24gZGlhbG9nLiBBdCB0aGUgc2FtZSBJIHRpbWUgZml4ZWQgYSBwcm9ibGVtIHdoZXJlIHRoZSBl eGNlcHRpb24gDQpkaWFsb2cgd291bGRuJ3QgYXBwZWFyIHJlZ2FyZGxlc3Mgb2YgdGhlIHNldHRp bmdzICh0aGUgY29kZSB3YXMgY29tbWVudGVkIA0Kb3V0IGZvciBzb21lIHJlYXNvbj8pLg0KDQpB bnl3YXkgSSBjYW4ndCByZXBlYXQgOTIgbm8gbWF0dGVyIGhvdyBoYXJkIEkgdHJ5LCBhbmQgd2Un dmUgaGFkIG5vIA0KcHJvYmxlbXMgYXQgUHJvZ3Jlc3NpdmUgd2l0aCBjY3RyYXkgcmVjb25uZWN0 aW5nIG9yIHRoZSBjb250ZXh0IG1lbnUgDQpkaXNhcHBlYXJpbmcgYW5kIHNvIEknbSBwcmV0dHkg Y29udmluY2VkIGl0J3MgZml4ZWQuDQoNCkNoZWVycw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNocmlzIEJyb3duDQpUaG91Z2h0V29ya3MgTHRk Lg0KZW1haWw6ICBjYnJvd25AdGhvdWdodHdvcmtzLmNvbQ0KY2VsbDogKzEgMzEyIDU2MCA2NDA2 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN Ck93ZW4gUm9nZXJzL0NhbmFkYS9UaG91Z2h0V29ya3MNCjI4LzA2LzIwMDQgMDk6MzgNCg0KVG8N CiJDcm9td2VsbCwgUnlhbiBGLiIgPHJjcm9td2VsbEBzc2FsbGMuY29tPkBUSE9VR0hUV09SS1Nf Q09NDQpjYw0KY2NuZXQtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0LCBDaHJpcyANCkJyb3du L1VLL1Rob3VnaHRXb3Jrc0BUaG91Z2h0V29ya3MsIFNyZWVrYW50aCANClZhZGFnaXJpL0luZGlh L1Rob3VnaHRXb3Jrc0BUaG91Z2h0V29ya3MNClN1YmplY3QNClJlOiBbQ2NuZXQtZGV2ZWxdIEND VHJheSBJc3N1ZXMgKDkyLCAxMTksIGV0YykNCg0KDQoNCg0KDQpoaSByeWFuLA0KdGhhbmtzIGZv ciB5b3VyIG9mZmVyLiAgaSB0aGluayB0aGF0IGNjbmV0LTkyIGlzIGFscmVhZHkgZml4ZWQgLS0g aSBjYW4ndCANCnJlbWVtYmVyIHdobyBmaXhlZCBpdCwgYnV0IGlmIHlvdSBkaWQgKGNocmlzPyBz cmVla2FudGg/KSBjb3VsZCB5b3UgcGxlYXNlIA0KcmVzb2x2ZSB0aGUgaXNzdWUgb24gamlyYS4N CjExOSBoYXNuJ3QgYmVlbiBzdGFydGVkIHlldCwgc28gYSBwYXRjaCBmb3IgdGhhdCB3b3VsZCBi ZSBhcHByZWNpYXRlZCA6KQ0KY2hlZXJzLA0Kb3dlbi4NCg0KLS0tDQpSLiBPd2VuIFJvZ2Vycw0K VGhvdWdodFdvcmtzIFRlY2hub2xvZ2llcyAoSW5kaWEpIFB2dCBMdGQuDQoNClRob3VnaHRXb3Jr cyAtIERlbGl2ZXIgd2l0aCBwYXNzaW9uIQ0KDQpUaG91Z2h0V29ya3MgaXMgYWx3YXlzIGxvb2tp bmcgZm9yIHRhbGVudGVkIHBlb3BsZSB3aG8gYXJlIHBhc3Npb25hdGUgDQphYm91dCB0ZWNobm9s b2d5LiAgVG8gZmluZCBvdXQgbW9yZSBhYm91dCBhIGNhcmVlciBhdCBUaG91Z2h0V29ya3MgZ28g dG8gDQpodHRwOi8vd3d3LnRob3VnaHR3b3Jrcy5jb20vY2FyZWVyLy4NCg0KDQoNCg0KIkNyb213 ZWxsLCBSeWFuIEYuIiA8cmNyb213ZWxsQHNzYWxsYy5jb20+DQpTZW50IGJ5OiBjY25ldC1kZXZl bC1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCjI4LzA2LzIwMDQgMTg6MjANCiANCiAgICAg ICAgVG86ICAgICA8Y2NuZXQtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KICAgICAgICBj YzogDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBbQ2NuZXQtZGV2ZWxdIENDVHJheSBJc3N1ZXMg KDkyLCAxMTksIGV0YykNCg0KDQpJcyBhbnlvbmUgd29ya2luZyBvbiB0aGUgaXNzdWVzIHRoYXQg aW52b2x2ZSBDQ1RyYXk/ICBJIGZpZ3VyZSBpdCBpcyBhYm91dCANCnRpbWUgSSBwdXQgaW4gc29t ZSBlZmZvcnQgaW4gbGlnaHQgb2YgaG93IG11Y2ggQ3J1aXNlQ29udHJvbC5OZXQgaGFzIA0KaGVs cGVkIHVzLiAgSSBkb27igJl0IHdhbnQgdG8gZHVwbGljYXRlIGVmZm9ydCB0aG91Z2guDQoNCg0K |
|
From: <ji...@pu...> - 2004-06-28 14:42:20
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- 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: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Versions: 0.7 Assignee: Reporter: Owen Rogers Created: Mon, 28 Jun 2004 7:39 AM Updated: Mon, 28 Jun 2004 7:39 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: Owen R. <OR...@th...> - 2004-06-28 14:28:04
|
hi ryan, thanks for your offer. i think that ccnet-92 is already fixed -- i can't=20 remember who fixed it, but if you did (chris? sreekanth?) could you please = resolve the issue on jira. 119 hasn't been started yet, so a patch for that would be appreciated :) cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate=20 about technology. To find out more about a career at ThoughtWorks go to=20 http://www.thoughtworks.com/career/. "Cromwell, Ryan F." <rcr...@ss...> Sent by: ccn...@li... 28/06/2004 18:20 =20 To: <ccn...@li...> cc:=20 Subject: [Ccnet-devel] CCTray Issues (92, 119, etc) Is anyone working on the issues that involve CCTray? I figure it is about = time I put in some effort in light of how much CruiseControl.Net has=20 helped us. I don?t want to duplicate effort though. |
|
From: Cromwell, R. F. <rcr...@ss...> - 2004-06-28 12:50:24
|
Is anyone working on the issues that involve CCTray? I figure it is about time I put in some effort in light of how much CruiseControl.Net has helped us. I don't want to duplicate effort though. |
|
From: <ji...@pu...> - 2004-06-28 08:16:18
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Mon, 28 Jun 2004 1:13 AM
i've submitted a fix for this. it is part of the recent ccnetlive builds and it will be included in the next release.
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-25
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-25
Summary: pvcstemp.txt file is not correct for some versions of PVCS
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Fix Fors:
0.7
Versions:
0.5
Assignee: Owen Rogers
Reporter: Owen Rogers
Created: Thu, 1 Apr 2004 3:30 AM
Updated: Mon, 28 Jun 2004 1:13 AM
Description:
The pvcs version I use containts a bug which prevents
cruiseControl.NET to operate.
The output generated by cruiseControl.NET in the file
pvcstemp.txt is not suited as
input for the pcli vlog statement. By substituting in the
file pvcstemp.txt in each line
that starts with a double slash, this double slash with
three slashes the problem is solved.
In this way, this bug has been circumvented in the java-
cruiseControl (see file pvcs.java).
Will cruiseControl.NET also be patched in this way?
---------------------------------------------------------------------
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-06-27 14:02:16
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Sun, 27 Jun 2004 7:00 AM
hi Gunnlaugur,
i've checked in your patch. i tried to write a test to simulate the failure, but i couldn't get the test to fail. do you have any idea what is required to simulate a failure due to the mismatch between the 2 encodings?
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-116
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-116
Summary: IntegrationStateManager saves files with the incorrect encoding.
Type: Bug
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.4.2
0.5
0.5 (CCNetLive)
0.6
0.6.1
Assignee:
Reporter:
Created: Wed, 23 Jun 2004 12:10 PM
Updated: Sun, 27 Jun 2004 7:00 AM
Environment: All
Description:
There is a mismatch between the encoding reported in the XML and the encoding the ccnet.state file is phsically saved as. The ccnet.state file reports it's encoding as UTF-16 (Unicode), when in fact it is saved as ASCII. Basically the StreamWriter object as instanciated in the existing code, without the encoding specified defauls to ASCII and not UNICODE (I know confusing because .NET treats text as UNICODE by default)
The IntegrationStateManager should return this:
return new StreamWriter(path, false, System.Text.Encoding.Unicode);
---------------------------------------------------------------------
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-06-27 13:59:16
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-119 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-119 Summary: CCTray should reload projects after server is restarted Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: CCTray Versions: 1.0 Assignee: Reporter: Owen Rogers Created: Sun, 27 Jun 2004 6:56 AM Updated: Sun, 27 Jun 2004 6:56 AM Description: Thanks Petrik, I know noticed this as well minutes after I sent this mail. -Brandon He Brandon I just started working with multiple projects aswell. My CCTray lost the projects aswell but that only happens if I start the CCTray before I start the CCServer (as far as I can tell now). So I think the trick is to have the CCServer running at the moment you start the CCTray. I am guessing that the CCTray only tries to update it's own project list directly after it is started and not after every time the server goes down and comes back up again. Hope it helps Regards Petrik Brandon Lonac wrote: Hello... I have configured the build (0.6.0.287) to use multiple projects. Looks good. I am having an issue with the cctray app though, it is not showing a list of the projects, it is empty. It is correctly connected to the server, display build notices and status, just not the project names. Here is the project xml I am using. Any help today would be great, I am heading out on vacation and I had hoped the other developers could use this while I was gone. --------------------------------------------------------------------- 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: Owen R. <OR...@th...> - 2004-06-27 13:07:05
|
i have to admit, i'm not overly keen. i think that the .net tracing functionality works well enough for our purposes currently. what i would prefer to see is for log4net to plug into the existing instrumentation, as a trace listener. this way you could still take advantage of the log4net appenders. cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. Mike Roberts <mi...@tm...> Sent by: ccn...@li... 24/06/2004 16:37 To: ccn...@li... cc: Subject: [Ccnet-devel] log4net over .NET tracing? Currently we use .NET tracing for logging in CruiseControl.NET. I was wondering if anyone had any opinion about switiching to log4net? If I had more spare time that I currently do, then I would implement such a change if there was support for it, but I thought I'd ask anyway. Personally I prefer log4net because of its better configuration and choice of appenders, but I may be biased since I'm used to log4j. Mike ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: <ji...@pu...> - 2004-06-27 13:04:16
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Sun, 27 Jun 2004 6:01 AM
hi loren,
sorry that it has taken so long to process your patch. i was intending to do it as part of some well-need refactoring on the ProjectIntegrator class, but i have yet to get around to that. however, it turns out that i was able to integrate your changes without needing to make the changes to the ProjectIntegrator. so, i've committed the changes as part of ccnetlive build 0.6.0.294. my solution is a bit different than yours, but it should both fix the daily schedule and allow the schedule to support forced builds (actually the force build functionality has now been moved out to the ProjectIntegrator where it belongs).
---------------------------------------------------------------------
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: Sun, 27 Jun 2004 6:01 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: Owen R. <OR...@th...> - 2004-06-27 13:03:40
|
hi loren, sorry that it has taken so long to process your patch. i was intending to do it as part of some well-need refactoring on the ProjectIntegrator class, but i have yet to get around to that. however, it turns out that i was able to integrate your changes without needing to make the changes to the ProjectIntegrator. so, i've committed the changes as part of ccnetlive build 0.6.0.294. my solution is a bit different than yours, but it should both fix the daily schedule and allow the schedule to support forced builds (actually the force build functionality has now been moved out to the ProjectIntegrator where it belongs). cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate about technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. ji...@pu... Sent by: ccn...@li... 24/06/2004 22:07 To: ccn...@li... cc: Subject: [Ccnet-devel] [JIRA] Commented: (CCNET-79) Daily schedule doesn't work right The following comment has been added to this issue: Author: Loren Halvorson Created: Thu, 24 Jun 2004 9:36 AM Body: We have come to rely on a combination of continuous builds and DailySchedule builds for building our products. The continous ones are throw-away intra-day builds, and the DailySchedule's are run at night and do a few more publishing/archiving steps. Here's an improved fix for the daily schedule than the one I gave in the original issue report. This one sets the next integration time in ShouldRunIntegration() instead of in IntegrationCompleted(). (Look for //*** delimiting all added code). We've been running this for quite some time now and it's working great! I'd sure like to see this trivial change get in so I don't have to hack the code every release. The other change we really need is some way to force a DailySchedule build (I used reflection to invoke ForceBuild() in ProjectIntegrator.cs, see the code in the original issue report for one possible solution). This is another hack I need to make every release. Thanks --Loren -----------DailySchedule.cs---------- 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() { } public BuildCondition ShouldRunIntegration() { //*** if (_forceNextBuild) { _forceNextBuild = false; return BuildCondition.ForceBuild; } //*** if (Now > _nextIntegration) { //*** DateTime now = Now; _nextIntegration = new DateTime(now.Year, now.Month, now.Day+1, _integrationTime.Hours, _integrationTime.Minutes, 0, 0); //*** return BuildCondition.IfModificationExists; } return BuildCondition.NoBuild; } protected virtual DateTime Now { get { return DateTime.Now; } } } } --------------------------------------------------------------------- View this comment: http://jira.public.thoughtworks.org/browse/CCNET-79?page=comments#action_10233 --------------------------------------------------------------------- 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: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Schedule Versions: 0.6 Assignee: Reporter: Created: Fri, 7 May 2004 7:13 AM Updated: Thu, 24 Jun 2004 9:36 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 ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: <ji...@pu...> - 2004-06-27 11:33:18
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Sun, 27 Jun 2004 4:30 AM
the problem was caused from looking up a null email address in the users ' hashtable. this is fixed in ccnetlive build: 0.6.0.293
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-21
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-21
Summary: Modifications generated by FileSystem SC break EmailPublisher (Wilka Hudson)
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Publisher
Fix Fors:
0.7
Versions:
0.5
Assignee: Owen Rogers
Reporter: Owen Rogers
Created: Wed, 31 Mar 2004 9:18 PM
Updated: Sun, 27 Jun 2004 4:30 AM
Description:
After seeing that you can setup Ccnet to monitor changes in the filesystem
(I'd never realised it could be setup that way before, but it's great!) I've
started using it, just like it shows on
http://confluence.public.thoughtworks.org/display/CCNET/Configuration but it
seems that the email publisher can't handle the output of filesystem
modifications - it seems to be looking for a username for the person that
made the change, but the filesystem there isn't one so it just blows up
instead.
---------------------------------------------------------------------
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-06-27 11:19:18
|
Message:
The following issue has been resolved as FIXED.
Resolver: Owen Rogers
Date: Sun, 27 Jun 2004 4:17 AM
fixed in build: 0_6_0_292 on ccnetlive:
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-118
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-118
Summary: Pb with VSS history parsing when a project contains a folder named "added"
Type: Bug
Status: Resolved
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
0.7
Versions:
0.6.1
Assignee:
Reporter:
Created: Fri, 25 Jun 2004 12:51 AM
Updated: Sun, 27 Jun 2004 4:17 AM
Environment: VS.NET 2003, CC 0.6.1
Description:
One of my VS.NET projects has a source folder named "added"
This causes an error in CC when it parses the history :
25.06.2004 09:12:00: [MyProject.NET:Error]: INTERNAL ERROR: Length cannot be less than zero.
Parameter name: length
----------
System.ArgumentOutOfRangeException: Length cannot be less than zero.
Parameter name: length
at System.String.Substring(Int32 startIndex, Int32 length)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VSSParser.ParseFileNameOther(String type) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 209
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.AddedParser.ParseFileName() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 258
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VSSParser.Parse() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 143
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.AddedParser.Parse() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 244
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VssHistoryParser.parseModifications(String[] entries) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 40
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VssHistoryParser.Parse(TextReader history, DateTime from, DateTime to) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 25
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.ParseModifications(TextReader reader, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 76
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.ParseModifications(ProcessResult result, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 71
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 45
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vss.GetModifications(DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\Vss.cs:line 82
at ThoughtWorks.CruiseControl.Core.Project.GetSourceModifications(IntegrationResult results) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\Project.cs:line 179
at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\Project.cs:line 158
######################
######################
Workaround : rename the folder to something else and it works
---------------------------------------------------------------------
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-06-26 15:50:27
|
Hi Tim, This is the CruiseControl.NET email list, not the CruiseControl (Java) email list. You can sign up to the CC list at http://sourceforge.net/mail/?group_id=23523. Cheers, Mike Tim Shadel wrote: > Hi, > > I wrote a patch for CC-40, but didn't see a file upload link on JIRA > (that's the way the Maven project accepts patches). I thought I'd > submit it here instead. The patch fixes the bug, and adds a test for > it. The details of the bug are listed in the description here: > > http://jira.public.thoughtworks.org/browse/CC-40 |
|
From: Tim S. <tim...@po...> - 2004-06-25 18:07:36
|
Hi, I wrote a patch for CC-40, but didn't see a file upload link on JIRA (that's the way the Maven project accepts patches). I thought I'd submit it here instead. The patch fixes the bug, and adds a test for it. The details of the bug are listed in the description here: http://jira.public.thoughtworks.org/browse/CC-40 Thanks for your help! Tim |
|
From: <ji...@pu...> - 2004-06-25 07:54:14
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-118 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-118 Summary: Pb with VSS history parsing when a project contains a folder named "added" Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Versions: 0.6.1 Assignee: Reporter: Created: Fri, 25 Jun 2004 12:51 AM Updated: Fri, 25 Jun 2004 12:51 AM Environment: VS.NET 2003, CC 0.6.1 Description: One of my VS.NET projects has a source folder named "added" This causes an error in CC when it parses the history : 25.06.2004 09:12:00: [MyProject.NET:Error]: INTERNAL ERROR: Length cannot be less than zero. Parameter name: length ---------- System.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name: length at System.String.Substring(Int32 startIndex, Int32 length) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VSSParser.ParseFileNameOther(String type) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 209 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.AddedParser.ParseFileName() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 258 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VSSParser.Parse() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 143 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.AddedParser.Parse() in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 244 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VssHistoryParser.parseModifications(String[] entries) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 40 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.VssHistoryParser.Parse(TextReader history, DateTime from, DateTime to) in c:\sbt\downloadz\cruisecontrol.net.source\project\core\sourcecontrol\vsshistoryparser.cs:line 25 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.ParseModifications(TextReader reader, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 76 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.ParseModifications(ProcessResult result, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 71 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\ProcessSourceControl.cs:line 45 at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vss.GetModifications(DateTime from, DateTime to) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\sourcecontrol\Vss.cs:line 82 at ThoughtWorks.CruiseControl.Core.Project.GetSourceModifications(IntegrationResult results) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\Project.cs:line 179 at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in C:\sbt\downloadz\CruiseControl.NET.source\project\core\Project.cs:line 158 ###################### ###################### Workaround : rename the folder to something else and it works --------------------------------------------------------------------- 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-06-24 16:39:13
|
The following comment has been added to this issue:
Author: Loren Halvorson
Created: Thu, 24 Jun 2004 9:36 AM
Body:
We have come to rely on a combination of continuous builds and DailySchedule builds for building our products. The continous ones are throw-away intra-day builds, and the DailySchedule's are run at night and do a few more publishing/archiving steps.
Here's an improved fix for the daily schedule than the one I gave in the original issue report. This one sets the next integration time in ShouldRunIntegration() instead of in IntegrationCompleted(). (Look for //*** delimiting all added code).
We've been running this for quite some time now and it's working great! I'd sure like to see this trivial change get in so I don't have to hack the code every release.
The other change we really need is some way to force a DailySchedule build (I used reflection to invoke ForceBuild() in ProjectIntegrator.cs, see the code in the original issue report for one possible solution). This is another hack I need to make every release.
Thanks
--Loren
-----------DailySchedule.cs----------
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()
{
}
public BuildCondition ShouldRunIntegration()
{
//***
if (_forceNextBuild)
{
_forceNextBuild = false;
return BuildCondition.ForceBuild;
}
//***
if (Now > _nextIntegration)
{
//***
DateTime now = Now;
_nextIntegration = new DateTime(now.Year, now.Month, now.Day+1, _integrationTime.Hours, _integrationTime.Minutes, 0, 0);
//***
return BuildCondition.IfModificationExists;
}
return BuildCondition.NoBuild;
}
protected virtual DateTime Now
{
get { return DateTime.Now; }
}
}
}
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-79?page=comments#action_10233
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Schedule
Versions:
0.6
Assignee:
Reporter:
Created: Fri, 7 May 2004 7:13 AM
Updated: Thu, 24 Jun 2004 9:36 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. <mi...@tm...> - 2004-06-24 11:07:24
|
Currently we use .NET tracing for logging in CruiseControl.NET. I was wondering if anyone had any opinion about switiching to log4net? If I had more spare time that I currently do, then I would implement such a change if there was support for it, but I thought I'd ask anyway. Personally I prefer log4net because of its better configuration and choice of appenders, but I may be biased since I'm used to log4j. Mike |
|
From: <ji...@pu...> - 2004-06-23 19:16:14
|
The following comment has been added to this issue:
Author: Gunnlaugur Thor Briem
Created: Wed, 23 Jun 2004 12:14 PM
Body:
I forgot to log in before submitting this issue; this comment is just so that you can reach me for any more details or testing.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-117?page=comments#action_10231
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-117
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-117
Summary: Wrong charset for non-ASCII chars in VSS checkin messages
Type: Bug
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Versions:
0.6.1
Assignee:
Reporter:
Created: Wed, 23 Jun 2004 12:10 PM
Updated: Wed, 23 Jun 2004 12:14 PM
Environment: CruiseControl and its web app are running on Windows Server 2003 with .Net 1.1. Don't know the platform SourceSafe is running on; I'm fairly sure it's the latest released version/service pack of SourceSafe though.
Description:
When non-ASCII characters appear in check-in messages, they are displayed incorrectly in the CruiseControl.Net webapp (under "Modifications since last build (X)". The characters display correctly when viewed in "History" in SourceSafe itself.
I assigned this to "Source Control" rather than "Web App" here in Jira; that was simply guesswork on my part (I find VSS somehow likely to violate reasonable expectations wherever it can :)
---------------------------------------------------------------------
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-06-23 19:14:15
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-117 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-117 Summary: Wrong charset for non-ASCII chars in VSS checkin messages Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Source Control Versions: 0.6.1 Assignee: Reporter: Created: Wed, 23 Jun 2004 12:10 PM Updated: Wed, 23 Jun 2004 12:10 PM Environment: CruiseControl and its web app are running on Windows Server 2003 with .Net 1.1. Don't know the platform SourceSafe is running on; I'm fairly sure it's the latest released version/service pack of SourceSafe though. Description: When non-ASCII characters appear in check-in messages, they are displayed incorrectly in the CruiseControl.Net webapp (under "Modifications since last build (X)". The characters display correctly when viewed in "History" in SourceSafe itself. I assigned this to "Source Control" rather than "Web App" here in Jira; that was simply guesswork on my part (I find VSS somehow likely to violate reasonable expectations wherever it can :) --------------------------------------------------------------------- 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-06-23 19:12:13
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-116 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-116 Summary: IntegrationStateManager saves files with the incorrect encoding. Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Versions: 0.4.2 0.5 0.5 (CCNetLive) 0.6 0.6.1 Assignee: Reporter: Created: Wed, 23 Jun 2004 12:10 PM Updated: Wed, 23 Jun 2004 12:10 PM Environment: All Description: There is a mismatch between the encoding reported in the XML and the encoding the ccnet.state file is phsically saved as. The ccnet.state file reports it's encoding as UTF-16 (Unicode), when in fact it is saved as ASCII. Basically the StreamWriter object as instanciated in the existing code, without the encoding specified defauls to ASCII and not UNICODE (I know confusing because .NET treats text as UNICODE by default) The IntegrationStateManager should return this: return new StreamWriter(path, false, System.Text.Encoding.Unicode); --------------------------------------------------------------------- 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-06-22 22:41:16
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-115 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-115 Summary: Reformat Test Details page and show it collapsed on front page Type: Improvement Status: Open Priority: Major Original Estimate: 2 days Time Spent: Unknown Remaining: 2 days Project: CruiseControl .NET Components: Web Site Assignee: Vivek Vaid Reporter: Vivek Vaid Created: Tue, 22 Jun 2004 3:39 PM Updated: Tue, 22 Jun 2004 3:39 PM Description: Reformat the test details page. - use icons for success/failuer/ignored - other reformatting - expand successful tests (not available currently) - show test details ( collapsed ) on the main build page. PS. I have a screen shot but don't see a way to attach it here. --------------------------------------------------------------------- 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-06-22 13:47:12
|
The following comment has been added to this issue:
Author:
Created: Tue, 22 Jun 2004 6:44 AM
Body:
The problem seems to be wider that just errors in test fixtures. Using the explicit NUnit task (rather than as part of a NAnt build) it seems to report build success irrespective of whether there are any test failures (in setup or otherwise).
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-66?page=comments#action_10223
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-66
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-66
Summary: Not showing error on fixture error
Type: Bug
Status: Unassigned
Priority: Critical
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Publisher
Versions:
0.4.2
Assignee:
Reporter:
Created: Thu, 22 Apr 2004 8:41 AM
Updated: Tue, 22 Jun 2004 6:44 AM
Description:
If you make a nunit testfixture with fixturesetup, and it breaks, CCNET shows it as a correct build. I think this is a large issue, I don't know whether it was fixed since 0.4.2.
---------------------------------------------------------------------
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
|