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
(1) |
2
|
3
|
|
4
|
5
|
6
(2) |
7
(5) |
8
(1) |
9
(2) |
10
|
|
11
(5) |
12
(9) |
13
(3) |
14
(3) |
15
(2) |
16
|
17
|
|
18
(2) |
19
(2) |
20
(10) |
21
(10) |
22
(16) |
23
(5) |
24
(1) |
|
25
(1) |
26
(1) |
27
(3) |
28
(1) |
29
(4) |
30
(5) |
|
|
From: Garrett S. <GS...@th...> - 2004-04-30 22:45:51
|
I'm wrapping up a VSS implementation that uses the COM API via unmanaged C++. This will solve a host of problems, including the label command line quirks and non-English VSS installations breaking CCNet. One problem I'm running in to is loading the type from the configuration [see stack trace below]; it can't find my class that has a ReflectorTypeAttribute. I think this is because CCNet only looks for source controls in the core DLL. I couldn't immediately tell from the source whether this is the case and NetReflector is a black box to me. For a couple reasons* the new source control is in its own DLL. One solution would be to create a proxy class in core that has the required properties and attributes, then uses reflection to create the types in the other DLL. This avoids the problem of circular references between core and my new DLL. Another solution is to merge the types in the core DLL even though they're written in a C++ project. I'm not sure whether that's possible, not to mention how to do it. Best, Garrett * Reasons: 1) It's C++, not C# 2) It makes the build easier. [CruiseControl Server:Error]: Exception: Unable to instantiate CruiseControl projects from configuration document. Configuration document is likely missing Xml nodes required for properly populating CruiseControl configuration.Type with NetReflector name "vssWithCom" does not exist. The name may be incorrect or the assembly containing the type might not be loaded. Xml: <sourcecontrol type="vssWithCom"><project>"$/LogView/Source/Current"</project><username>gsmim</username><password>a</password><ssdir>C:\vsslogview\</ssdir><applyLabel>true</applyLabel></sourcecontrol> ---------- ThoughtWorks.CruiseControl.Core.Config.ConfigurationException: Unable to instantiate CruiseControl projects from configuration document. Configuration document is likely missing Xml nodes required for properly populating CruiseControl configuration.Type with NetReflector name "vssWithCom" does not exist. The name may be incorrect or the assembly containing the type might not be loaded. Xml: <sourcecontrol type="vssWithCom"><project>"$/LogView/Source/Current"</project><username>gsmim</username><password>a</password><ssdir>C:\vsslogview\</ssdir><applyLabel>true</applyLabel></sourcecontrol> ---> Exortech.NetReflector.NetReflectorException: Type with NetReflector name "vssWithCom" does not exist. The name may be incorrect or the assembly containing the type might not be loaded. Xml: <sourcecontrol type="vssWithCom"><project>"$/LogView/Source/Current"</project><username>gsmim</username><password>a</password><ssdir>C:\vsslogview\</ssdir><applyLabel>true</applyLabel></sourcecontrol> at Exortech.NetReflector.XmlMemberSerialiser.GetTargetType(XmlNode childNode, NetReflectorTypeTable table) at Exortech.NetReflector.XmlMemberSerialiser.Read(XmlNode node, NetReflectorTypeTable table) at Exortech.NetReflector.XmlTypeSerialiser.ReadMembers(XmlNode node, Object instance, NetReflectorTypeTable table) at Exortech.NetReflector.XmlTypeSerialiser.Read(XmlNode node, NetReflectorTypeTable table) at Exortech.NetReflector.NetReflector.Read(XmlNode node, NetReflectorTypeTable table) at ThoughtWorks.CruiseControl.Core.Config.ConfigurationLoader.PopulateProjectsFromXml(XmlDocument configXml) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\configuration\ConfigurationLoader.cs:line 111 --- End of inner exception stack trace --- at ThoughtWorks.CruiseControl.Core.Config.ConfigurationLoader.PopulateProjectsFromXml(XmlDocument configXml) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\configuration\ConfigurationLoader.cs:line 119 at ThoughtWorks.CruiseControl.Core.Config.ConfigurationLoader.Load() in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\configuration\ConfigurationLoader.cs:line 60 at ThoughtWorks.CruiseControl.Core.Config.ConfigurationContainer..ctor(IConfigurationLoader loader, IFileWatcher watcher) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\configuration\ConfigurationContainer.cs:line 20 at ThoughtWorks.CruiseControl.Core.Config.ConfigurationContainer..ctor(String filename) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\configuration\ConfigurationContainer.cs:line 14 at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.CreateLocal(String configFile) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\CruiseServerFactory.cs:line 12 at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.Create(Boolean remote, String configFile) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\core\CruiseServerFactory.cs:line 22 at ThoughtWorks.CruiseControl.Console.ConsoleRunner..ctor(ArgumentParser parser) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\console\ConsoleRunner.cs:line 29 at ThoughtWorks.CruiseControl.Console.ConsoleRunner.Main(String[] args) in C:\Allstate\AllCorp\Tools\Source\Current\CRUISECONTROL\src\project\console\ConsoleRunner.cs:line 18 ---------- |
|
From: Garrett S. <GS...@th...> - 2004-04-30 22:45:51
|
What do people think of including story tests for CCNet? By story tests, I mean tests that exercise a feature end-to-end and do not fail the build if it fails. I've noticed the definition of a story test varies depending on the person, for better or worse. ... There have been a couple regression errors with external (process) source control tools because our unit tests do not actually run the executable. In my short time working with the source control classes I've experienced at least three of these regression errors. If we were to write story tests around, for example, the VSS label feature, we'd have automatic notification of a problem. For now, we'd have to modify the build to run story tests for a given source control only if it was installed on the local machine. ClearCase, for example, is so god awful expensive that I doubt we'll have in on our build machine. NUnit categories will make this easier in the future. I'd be willing to do story tests for VSS. Best, Garrett |
|
From: Simon P. <sr...@ei...> - 2004-04-30 15:29:55
|
I just switched my ccnet installation to the current version of nant and
found my build reports were misbehaving. I'm using the usual bootstrap
arrangement with a simple nant buildfile that updates my source tree
from version control and then invokes nant on the "real" buildfile. With
a straightforward single buildfile everything works as before, when I
use the usual bootstrap arrangement the xml logger appears to get
confused with the result that much of the log file is repeated - unit
test results get printed twice etc.
=20
I tried replacing nant's XmlLogger.cs with the previous version (1.11 in
place of 1.12) and all seems well with the world. I've also run some
tests outside ccnet and it does appear that the issue is with nant,
rather than ccnet.
=20
Has anyone else encountered, or even better - fixed, this problem? If
not then I'll look into it and try to provide a patch to the nant team.
=20
Cheers,
Simon
|
|
From: Simon P. <sr...@ei...> - 2004-04-30 15:22:45
|
Hi Clayton, Not sure if you've resolved this yourself but just in case... I had the same problem with the email publisher. As far as I know there is not configuration setting but the code is in the HTML message builder, but is commented out for some reason I'm not aware of. I uncommented the line and everything appears to work, although you also need to modify the unit test to include the link, rather than the straight text of the URL. The files you need to modify are: (ccnet-home)/project/core/publishers/HtmlLinkMessageBuilder.cs and (ccnet-home)/project/core/publishers/HtmlLinkMessageBuilderTest.cs and The change to the builder is pretty obvious and the test is pretty straightforward to correct, but let me know if you need a patch. Also, if anyone knows why the link is commented out, I'd be interested to know. If there isn't a current reason then I'll submit a patch for review and we can fix this for everyone. Cheers, Simon -----Original Message----- From: ccn...@li... [mailto:ccn...@li...] On Behalf Of Clayton Harbour Sent: 25 April 2004 19:51 To: ccn...@li... Subject: [Ccnet-devel] email publishing - "clickable" project link Hi, I am just wondering if there is a configuration setting to produce "clickable" project links for the email publisher? I have tried including project details (simply because the output is in html rather than plain text), but that does not seem to work. Is this possible? Cheers, Clayton ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Owen R. <OR...@th...> - 2004-04-30 06:44:52
|
if you are experiencing problems trying to access the ccnet CVS repository on sourceforge (or any other sourceforge project repository for that matter), it may be because of the fact that sourceforge has changed its dns mappings for entries that look like: cvs.<project>.sourceforge.net. you can fix this by just using the cvs.sourceforge.net dns instead. it certainly would have been nice if sourceforge had provided some notification of this change. 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/. |
|
From: <mik...@th...> - 2004-04-29 12:47:51
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-70 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-70 Summary: CCTray balloon misspells successful as succesful. Type: Bug Status: Unassigned Priority: Trivial Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: CCTray Versions: 0.6 Assignee: Reporter: Created: Thu, 29 Apr 2004 5:46 AM Updated: Thu, 29 Apr 2004 5:46 AM Environment: Windows XP Description: Yet another succe--->s<---ful build. Need another 's' --------------------------------------------------------------------- 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: <mik...@th...> - 2004-04-29 12:19:52
|
The following comment has been added to this issue:
Author:
Created: Thu, 29 Apr 2004 5:18 AM
Body:
Yes the link back was exactly what i was referring too. A consolidation of the web interface as you are suggesting would be quite helpful. I also made a note on one of the dashboard pages that an httpModule may be a good option for eliminating the need for a vdir per project. I will cc you on a message to the Devel mailing list that includes our ideas.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-55?page=comments#action_10113
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-55
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-55
Summary: Dashboard interface improvements
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
1.0
Versions:
0.6
Assignee:
Reporter: Mike Roberts
Created: Sun, 18 Apr 2004 2:53 PM
Updated: Thu, 29 Apr 2004 5:18 AM
Description:
The dashboard could do with the following improvements:
- The columns could be better, e.g. what is 'CCNet status' ?
- Would be good to have the server version reported
---------------------------------------------------------------------
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: <mik...@th...> - 2004-04-29 09:52:52
|
The following comment has been added to this issue:
Author: Mike Roberts
Created: Thu, 29 Apr 2004 2:51 AM
Body:
Do you mean when you click through to a project's web page you'd like to be able to link back to the dashboard? If so, I agree. In fact I hope that the the dashboard and per-project web apps will be combined, but this won't happen for a while.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-55?page=comments#action_10112
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-55
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-55
Summary: Dashboard interface improvements
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
1.0
Versions:
0.6
Assignee:
Reporter: Mike Roberts
Created: Sun, 18 Apr 2004 2:53 PM
Updated: Thu, 29 Apr 2004 2:51 AM
Description:
The dashboard could do with the following improvements:
- The columns could be better, e.g. what is 'CCNet status' ?
- Would be good to have the server version reported
---------------------------------------------------------------------
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: <as...@th...> - 2004-04-29 01:01:48
|
o The FBI project has been created: http://sourceforge.net/projects/fbi/ o The previous description: http://docs.codehaus.org/display/DC/Remote+API?showComments=true#comments (contents will be moved to FBI's docs) o Some initial code is checked in to the 'fbi' CVS module o Mailing list created (fbi...@li...) - Let's continue discussion there now. o All CC/CC.NET/DC/BB developers are invited to join (just let us know your SF id on fbi...@li...) Cheers, Aslak |
|
From: <mik...@th...> - 2004-04-28 21:16:51
|
The following comment has been added to this issue:
Author:
Created: Wed, 28 Apr 2004 2:15 PM
Body:
A link back to the (referring?) Dashboard would be useful as well.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-55?page=comments#action_10111
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-55
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-55
Summary: Dashboard interface improvements
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Fix Fors:
1.0
Versions:
0.6
Assignee:
Reporter: Mike Roberts
Created: Sun, 18 Apr 2004 2:53 PM
Updated: Wed, 28 Apr 2004 2:15 PM
Description:
The dashboard could do with the following improvements:
- The columns could be better, e.g. what is 'CCNet status' ?
- Would be good to have the server version reported
---------------------------------------------------------------------
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: Cromwell, R. F. <rcr...@ss...> - 2004-04-27 19:36:11
|
Has there been any talk of using an httpModule to eliminate the need for creating multiple virtual directories? Would that be of interest to anyone? I don't know if you are willing to add features after the release of an RC, but I can imagine it being a big productivity plus. It's almost mandatory here at my office. =20 Ryan Cromwell =20 |
|
From: <mik...@th...> - 2004-04-27 15:05:29
|
The following comment has been added to this issue:
Author: Garrett Smith
Created: Tue, 27 Apr 2004 8:04 AM
Body:
I'm fairly sure I fixed this problem last week Thursday, but am talking with Craig Neuwirt about a similar problem he's reported (http://sourceforge.net/tracker/index.php?func=detail&aid=918748&group_id=71179&atid=535542).
I'll investigate and close this issue when I'm done.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-69?page=comments#action_10101
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-69
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-69
Summary: VSS ApplyLabel function not working
Type: Bug
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
Source Control
Versions:
0.6
Assignee:
Reporter:
Created: Mon, 26 Apr 2004 1:10 PM
Updated: Tue, 27 Apr 2004 8:04 AM
Environment: CCNet 0.6 RC1, VSS 6.0d
Description:
I was trying to make the ApplyLabel functionality work as I found mentioned in a list post.
Anyway, two things...
First the format of the command is wrong:
internal static readonly string LABEL_COMMAND_FORMAT = @"label {0} -VL{1} -Vd{2} -Y{3},{4} -I-Y";
It should be '-L(1)' not '-VL(1)'
Second, and this probably has more to do with VSS, but when I use the '-Vd...' parameter in applying labels, it seems to act as though it's placing a label on the files, but it does not show up in the 'Show History' report.
---------------------------------------------------------------------
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: <mik...@th...> - 2004-04-27 13:40:27
|
The following comment has been added to this issue:
Author: Thibaut Barr=C3=A8re
Created: Tue, 27 Apr 2004 6:39 AM
Body:
This is already implemented, my mistake.
What got me wrong is that you actually need to force the build twice in ord=
er for ccnet.config to be updated by the boostrapper.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-46?page=3Dcomments#actio=
n_10100
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-46
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-46
Summary: Hot reloading of ccnet.config file
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:=20
Builder
Assignee:=20
Reporter: Thibaut Barr=C3=A8re
Created: Wed, 14 Apr 2004 8:38 AM
Updated: Tue, 27 Apr 2004 6:39 AM
Description:
A hot reloading of the project configuration file (ccnet.config or other), =
which would be triggered by ccnet.config file monitoring (or by any other m=
ean such as remoting), would ease implementations and everyday use of CCNet=
by either allowing :
- to update ccnet.config without requiring more than a network share to do =
the job
- to include ccnet.config in the source control tree and rely on the bootst=
rap to propagate changes of configuration to the CC server
- to avoid stopping/restarting ccnet.exe or the service version
A secure guard would be useful as well (i.e. checking if the new ccnet.conf=
ig is valid, and keep on using the former version if it's not).
Are there any plans to implement such an improvement ?
I can contribute to this if external contributors are welcome.
Regards,
Thibaut Barr=C3=A8re
---------------------------------------------------------------------
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: <mik...@th...> - 2004-04-26 20:11:29
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-69 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-69 Summary: VSS ApplyLabel function not working Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: Source Control Versions: 0.6 Assignee: Reporter: Created: Mon, 26 Apr 2004 1:10 PM Updated: Mon, 26 Apr 2004 1:10 PM Environment: CCNet 0.6 RC1, VSS 6.0d Description: I was trying to make the ApplyLabel functionality work as I found mentioned in a list post. Anyway, two things... First the format of the command is wrong: internal static readonly string LABEL_COMMAND_FORMAT = @"label {0} -VL{1} -Vd{2} -Y{3},{4} -I-Y"; It should be '-L(1)' not '-VL(1)' Second, and this probably has more to do with VSS, but when I use the '-Vd...' parameter in applying labels, it seems to act as though it's placing a label on the files, but it does not show up in the 'Show History' report. --------------------------------------------------------------------- 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: Clayton H. <cla...@sp...> - 2004-04-25 19:20:54
|
Hi, I am just wondering if there is a configuration setting to produce = "clickable" project links for the email publisher? I have tried = including project details (simply because the output is in html rather = than plain text), but that does not seem to work. Is this possible? Cheers, Clayton |
|
From: <mik...@th...> - 2004-04-24 12:22:31
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-68 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-68 Summary: CCTray freezing Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components:=20 CCTray Assignee:=20 Reporter: Thibaut Barr=C3=A8re Created: Sat, 24 Apr 2004 5:20 AM Updated: Sat, 24 Apr 2004 5:20 AM Description: Depending on the choosen polling interval, CCTray may hang up. On some mach= ines, increasing the polling interval is actually not enough to avoid freez= ing. This is especially true when the CC server is down. AFAIK polling is achieved synchronously in the UI thread today, switching t= o asynchronous calls would make a more robust CCTray and provide better use= r experience. --------------------------------------------------------------------- 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: Clayton H. <cla...@sp...> - 2004-04-23 12:44:53
|
Sorry Owen the site should have been: http://kermit.symbiote.sporadicism.com/ccnet I took a look at the link and this looks like exactly what I want, thanks! BTW, when did you upgrade to confluence? Is this fairly recent or have I been missing out? :-). =20 Cheers, Clayton=20 > -----Original Message----- > From: Owen Rogers [mailto:OR...@th...]=20 > Sent: April 22, 2004 11:15 PM > To: Clayton Harbour > Cc: ccn...@li... > Subject: RE: [Ccnet-devel] ccnetlive labels >=20 >=20 >=20 >=20 >=20 >=20 > hi clayton, > this is what we do on the ccnet web site. if you look at the=20 > dist.publish target at the bottom of the ccnet.build file,=20 > you will find some sample xml. the key thing is that ccnet=20 > passes the current build label through to nant using the nant=20 > property label-to-apply. i don't think that this has been=20 > very well documented, so i've updated the docs to reflect=20 > this:=20 > http://confluence.public.thoughtworks.org/display/CCNET/NAntBuilder > btw, it looks like your site is restricted. i can't seem to=20 > access it. cheers, owen. >=20 > --- > R. Owen Rogers > ThoughtWorks Technologies (India) Pvt Ltd. >=20 > ThoughtWorks - Deliver with passion! >=20 > ThoughtWorks is always looking for talented people who are=20 > passionate about technology. To find out more about a career=20 > at ThoughtWorks go to http://www.thoughtworks.com/career/. >=20 >=20 > |---------+---------------------------------------> > | | "Clayton Harbour" | > | | <claytonharbour@sporadicism.| > | | com> | > | | Sent by: | > | | ccn...@li...| > | | ceforge.net | > | | | > | | | > | | 22/04/2004 20:12 | > |---------+---------------------------------------> > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > | =20 > =20 > | > | To: <ccn...@li...> =20 > =20 > | > | cc: =20 > =20 > | > | Subject: RE: [Ccnet-devel] ccnetlive labels =20 > =20 > | > =20 > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| >=20 >=20 >=20 >=20 > Hi, >=20 > I have a project that requires me to run the same set of=20 > tests against a number of configuration settings. This=20 > produces test output files which I put in the ccnet website=20 > log directory under a date/ time currently. >=20 > I am then passing this (base) directory into my NAnt build=20 > file, and NAnt is producing a timestamp to creat a sub-folder=20 > under this directory, then copying the test results to this=20 > folder. I then have a link on the ccnet page that links to=20 > the root log directory, and the user can then browse to the=20 > correct build date (example at: http://kermit.symbiote.sporadicism.com > ). >=20 > What I would like to do is to pass the current label into=20 > NAnt. I could then use this to create the sub-folder and (I=20 > believe this is possible) modify the web page to link=20 > directory to this sub-directory. The other advantage of this=20 > approach is it would be more clear which build the test=20 > results belonged to, now there is some interpretation involved. >=20 > Is it possible to pass this into the NAnt build? Or would=20 > there be another way to copy these sub-builds to the=20 > appropriately labelled output directory under ccnet website? >=20 >=20 > Cheers, >=20 >=20 > Clayton >=20 >=20 > -----Original Message----- > From: Owen Rogers [mailto:OR...@th...] > Sent: Thu 4/22/2004 4:17 AM > To: ccn...@li... > Cc: > Subject: [Ccnet-devel] ccnetlive labels >=20 >=20 >=20 >=20 > i've changed the labels on ccnetlive from using dots '.' to=20 > using underscores '_'. the reason is that IIS has trouble=20 > browsing to folders containing dots in the folder name. so,=20 > the release distributables for builds 199-203 are=20 > downloadable. on a related note, if we were to use the build=20 > label to label the cvs repository, this would also create=20 > problems as cvs does not accept dots in its tags. cheers, owen. >=20 > --- > R. Owen Rogers > ThoughtWorks Technologies (India) Pvt Ltd. >=20 > ThoughtWorks - Deliver with passion! >=20 > ThoughtWorks is always looking for talented people who are=20 > passionate about technology. To find out more about a career=20 > at ThoughtWorks go to http://www.thoughtworks.com/career/. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President=20 > and CEO of GenToo technologies. Learn everything from=20 > fundamentals to system=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > Ccnet-devel mailing list > Ccn...@li...=20 > https://lists.sourceforge.net/lists/listinfo/c> cnet-devel >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President=20 > and CEO of GenToo technologies. Learn everything from=20 > fundamentals to system=20 > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick > _______________________________________________ > Ccnet-devel mailing list > Ccn...@li...=20 > https://lists.sourceforge.net/lists/listinfo/c> cnet-devel >=20 >=20 >=20 |
|
From: <mik...@th...> - 2004-04-23 10:03:25
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://jira.public.thoughtworks.org/browse/CCNET-67 Here is an overview of the issue: --------------------------------------------------------------------- Key: CCNET-67 Summary: Show 'Amber' icon when Building Type: Improvement Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: CruiseControl .NET Components: CCTray Fix Fors: 1.0 Versions: 0.6 Assignee: Reporter: Mike Roberts Created: Fri, 23 Apr 2004 3:02 AM Updated: Fri, 23 Apr 2004 3:02 AM Description: Currently CCTray shows 'green' when the build is good and 'red' when bad. What about showing 'yellow' when a build is in process? --------------------------------------------------------------------- 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: <mik...@th...> - 2004-04-23 06:24:25
|
The following comment has been added to this issue:
Author: Owen Rogers
Created: Thu, 22 Apr 2004 11:23 PM
Body:
ok. interesting suggestion. thanks for logging the issue. we'll see what we can do.
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-64?page=comments#action_10098
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-64
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-64
Summary: Getting sources after making successfull build
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
CCTray
Assignee:
Reporter:
Created: Thu, 22 Apr 2004 1:08 AM
Updated: Thu, 22 Apr 2004 11:23 PM
Description:
Let's see the problem of not getting synced with the code in the scc. The tray app may get the sources automatically after each successfull build, leaving the checked out or writable files. This would help letting all developers share the current and successfull sources.
---------------------------------------------------------------------
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-04-23 06:15:09
|
hi clayton, this is what we do on the ccnet web site. if you look at the dist.publ= ish target at the bottom of the ccnet.build file, you will find some sample= xml. the key thing is that ccnet passes the current build label throug= h to nant using the nant property label-to-apply. i don't think that this has been very well documented, so i've updated = the docs to reflect this: http://confluence.public.thoughtworks.org/display/CCNET/NAntBuilder btw, it looks like your site is restricted. i can't seem to access it.= cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate a= bout technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. |---------+---------------------------------------> | | "Clayton Harbour" | | | <claytonharbour@sporadicism.| | | com> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 22/04/2004 20:12 | |---------+---------------------------------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| | = = | | To: <ccn...@li...> = = | | cc: = = | | Subject: RE: [Ccnet-devel] ccnetlive labels = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| Hi, I have a project that requires me to run the same set of tests against = a number of configuration settings. This produces test output files whic= h I put in the ccnet website log directory under a date/ time currently. I am then passing this (base) directory into my NAnt build file, and NA= nt is producing a timestamp to creat a sub-folder under this directory, th= en copying the test results to this folder. I then have a link on the ccn= et page that links to the root log directory, and the user can then browse= to the correct build date (example at: http://kermit.symbiote.sporadicism.= com ). What I would like to do is to pass the current label into NAnt. I coul= d then use this to create the sub-folder and (I believe this is possible)= modify the web page to link directory to this sub-directory. The other= advantage of this approach is it would be more clear which build the te= st results belonged to, now there is some interpretation involved. Is it possible to pass this into the NAnt build? Or would there be ano= ther way to copy these sub-builds to the appropriately labelled output direc= tory under ccnet website? Cheers, Clayton -----Original Message----- From: Owen Rogers [mailto:OR...@th...] Sent: Thu 4/22/2004 4:17 AM To: ccn...@li... Cc: Subject: [Ccnet-devel] ccnetlive labels i've changed the labels on ccnetlive from using dots '.' to using underscores '_'. the reason is that IIS has trouble browsing to folder= s containing dots in the folder name. so, the release distributables for= builds 199-203 are downloadable. on a related note, if we were to use the build label to label the cvs repository, this would also create problems as cvs does not accept dots= in its tags. cheers, owen. --- R. Owen Rogers ThoughtWorks Technologies (India) Pvt Ltd. ThoughtWorks - Deliver with passion! ThoughtWorks is always looking for talented people who are passionate a= bout technology. To find out more about a career at ThoughtWorks go to http://www.thoughtworks.com/career/. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc= lick _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel = |
|
From: Owen R. <OR...@th...> - 2004-04-23 05:59:45
|
hi garrett, > I went with option 4, none of the above. I created a new interface, ITemporaryLabeller, which inherits from ISourceControl. Source controls that need to apply a temporary label (Vss, ClearCase) use it; those that don't, don't. looks good to me. small question, is there a reason that you are using 'typeof(x).IsInstanceTypeOf' instead of using the 'is' keyword? > I don't like the use of ITask, at least as it is currently used with the source control. i agree. initially most of the tasks in the workflow were relatively simple doing one specific thing. however, i'm increasingly looking at the tasks as components that could have responsibility for multiple steps in the build workflow. this makes the event-based DamageControl approach especially appealing. as it is right now, the Project class is too complex and too hard to test. the introduction of the ITask interface was an attempt to simplify the workflow by genericising the steps within it (as I've done with the Workflow class). however, this has proved to be too restrictive for the reasons that you mentioned. using an event-based architecture is an alternative approach to dealing with this problem that i think ultimately holds more promise. the challenge will be figuring out how to evolve the architecture to get there. 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/. |---------+----------------------------> | | Garrett Smith | | | | | | 23/04/2004 03:41 | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: ccn...@li... | | cc: Owen Rogers/Canada/ThoughtWorks@ThoughtWorks, William E Caputo/Corporate/ThoughtWorks/US@ThoughtWorks, Mike | | Roberts/UK/ThoughtWorks@ThoughtWorks | | Subject: Enhancing ISourceControl | >--------------------------------------------------------------------------------------------------------------------------------------------------| Owen, et. al: Owen wrote> my preference is probably 3 for the long term and 2 for the short term I went with option 4, none of the above. I created a new interface, ITemporaryLabeller, which inherits from ISourceControl. Source controls that need to apply a temporary label (Vss, ClearCase) use it; those that don't, don't. Project now invokes these methods if the source control is a ITemporaryLabeller. I modified MultiSourceControl. It executes the two new methods on ITemporaryLabeller if its children are of type ITemporaryLabeller. Finally, I modified Vss to implement the new interface. I agree that option 3 is the best long term. Owen wrote> it implements the ITask interface, which is the interface for all tasks in the generic ccnet workflow. ITask has a Run method that takes in an IntegrationResult, from which you can get whatever state information you might need. in the effort of moving ccnet towards better support for a generic workflow, i would be happy if we were to refactor the Project class to access its ISourceControl via the Run method, rather than by using the GetModifications interface. is this more or less what you had in mind? I don't like the use of ITask, at least as it is currently used with the source control. Source control really isn't one task, it is at least two: checking for modifications and applying a label. Now there are four, with the addition of CreateTemporaryLabel() and DeleteTemporaryLabel(). I see a role for ITask in CCNet, but don't understand why ISourceControl uses it. Owen wrote> as you brought it up, i would also like to move the QuietPeriod functionality out of the Project class. fundamentally it is a product of the shortcomings of particular SCMs and therefore it should be up to the SourceControl implementation to decide whether to use the quiet period or not. i think that there should be a QuietPeriod class that encapsulates this functionality that can be used by individual sourcecontrols if they so choose. in addition, currently the quiet period timeout is 0 seconds by default, which effectively disables the quiet period. i don't imagine that most people turn it on (probably cause they don't know about it) -- which is a bit of a problem. we need to be making things easier for them by enabling it by default for the SCs that need it. anyway, this is a separate discussion that i will be moving out onto the ccnet-devel list. I agree; this would be a good improvement. Best, Garrett *** My original message: *** Another source control design e-mail. This comes from a conversation I've had with Bill and Jason Borro. Both the VSS and ClearCase source control logic requires event notifications beyond what the current ISourceControl provides. Because of the way VSS works, a CCNETUNVERIFIED label is applied when modifications are detected. If the build is successful, that label is renamed to the proper version number, i.e. v1.2.3.4. If the build is unsuccessful, the label stays around forever. With ClearCase, we have a similar issue for different reasons. First, we need to know in GetModifications whether we're within the quiet period or not. If so, we do nothing. If not and there are modifications, we create a baseline. Second, we rename the baseline from a CCNETUNVERIFIED-like name to the version number if the build is successful. If not, we delete it. Both essentially required GetModifications and LabelSource control to be aware of the state of the build. Idea 1: Add new template methods to ISourceControl. LabelSourceControl becomes LabelSourceControlSuccess and LabelSourceControlFailure. GetModifications becomes GetModifications and GetModificationsQuietPeriod. I don't particularly like this idea, but it would work. Idea 2: Pass in some sort of state to GetModifications and LabelSourceControl. I've done this with our local Allstate branch by passing in the IntegrationResult, and it works. The problem is that it violates encapsulation in that the source control classes may modify the build state. We could get around this by using a state pattern and giving the source control classes a read-only view of this state. Idea 3: Use events, similar to the way the publishers work. Source control classes register for events and act on them with needed. I envision some sort of state would be passed in as the event args. My preference would be 3, then 2, then 1 as a last resort. 3 is more major of a change. Your thoughts? Garrett |
|
From: Mike R. <mi...@tm...> - 2004-04-22 23:52:40
|
CCNet folks, I've got some stuff working for this against CCNet - here's a copy of my=20 comment from DamageControl's confluence that Aslak linked: -- OK, I've tracer bulletted an implementation in .NET, both client and=20 server, running against CCNet. Its running on CCNetLive, so here are=20 some URLs 1) server, listing projects running on CCNetLive -=20 http://ccnetlive.thoughtworks.com/XMLRPCWebService/XMLRPC.rem^ 2) client - simple web page hitting (1) -=20 http://ccnetlive.thoughtworks.com/XMLRPCWebService/BasicTest.aspx^ 3) Source code is in CCNet CVS tree, or in the latest source zip at=20 http://ccnetlive.thoughtworks.com/CCNet-builds/0_6_0_210/CruiseControl.NE= T.source.zip^=20 I'm happy for us to use CCNet as a ref impl, but if you want to host in=20 Java and Ruby somewhere go ahead and I'll try to keep the CCNet Impl up=20 to date. -- Aslak Helles=F8y wrote: > Hi! > > At tonight's GeekNight in ThoughtWorks London several of us discussed=20 > how to achieve interop between various CI systems' clients by defining=20 > a standard (implementation neutral) API for various CI systems. > > Please don't reply to this mail, (as we have too many mailing lists,=20 > and none are subscribed to all of them). In stead, chip in and comment=20 > at the bottom of these pages, which are drafts of the suggested=20 > standard CI API: > > http://docs.codehaus.org/display/DC/Remote+API > http://docs.codehaus.org/display/DC/XML-RPC+Bridges > > (Alternatively we could set up a common mailing list for this - any=20 > volunteers?) > > It sould be great to consolidate this! > > Cheers, > Aslak > |
|
From: Garrett S. <GS...@th...> - 2004-04-22 22:16:40
|
Owen, et. al: Owen wrote> my preference is probably 3 for the long term and 2 for the short term I went with option 4, none of the above. I created a new interface, ITemporaryLabeller, which inherits from ISourceControl. Source controls that need to apply a temporary label (Vss, ClearCase) use it; those that don't, don't. Project now invokes these methods if the source control is a ITemporaryLabeller. I modified MultiSourceControl. It executes the two new methods on ITemporaryLabeller if its children are of type ITemporaryLabeller. Finally, I modified Vss to implement the new interface. I agree that option 3 is the best long term. Owen wrote> it implements the ITask interface, which is the interface for all tasks in the generic ccnet workflow. ITask has a Run method that takes in an IntegrationResult, from which you can get whatever state information you might need. in the effort of moving ccnet towards better support for a generic workflow, i would be happy if we were to refactor the Project class to access its ISourceControl via the Run method, rather than by using the GetModifications interface. is this more or less what you had in mind? I don't like the use of ITask, at least as it is currently used with the source control. Source control really isn't one task, it is at least two: checking for modifications and applying a label. Now there are four, with the addition of CreateTemporaryLabel() and DeleteTemporaryLabel(). I see a role for ITask in CCNet, but don't understand why ISourceControl uses it. Owen wrote> as you brought it up, i would also like to move the QuietPeriod functionality out of the Project class. fundamentally it is a product of the shortcomings of particular SCMs and therefore it should be up to the SourceControl implementation to decide whether to use the quiet period or not. i think that there should be a QuietPeriod class that encapsulates this functionality that can be used by individual sourcecontrols if they so choose. in addition, currently the quiet period timeout is 0 seconds by default, which effectively disables the quiet period. i don't imagine that most people turn it on (probably cause they don't know about it) -- which is a bit of a problem. we need to be making things easier for them by enabling it by default for the SCs that need it. anyway, this is a separate discussion that i will be moving out onto the ccnet-devel list. I agree; this would be a good improvement. Best, Garrett *** My original message: *** Another source control design e-mail. This comes from a conversation I've had with Bill and Jason Borro. Both the VSS and ClearCase source control logic requires event notifications beyond what the current ISourceControl provides. Because of the way VSS works, a CCNETUNVERIFIED label is applied when modifications are detected. If the build is successful, that label is renamed to the proper version number, i.e. v1.2.3.4. If the build is unsuccessful, the label stays around forever. With ClearCase, we have a similar issue for different reasons. First, we need to know in GetModifications whether we're within the quiet period or not. If so, we do nothing. If not and there are modifications, we create a baseline. Second, we rename the baseline from a CCNETUNVERIFIED-like name to the version number if the build is successful. If not, we delete it. Both essentially required GetModifications and LabelSource control to be aware of the state of the build. Idea 1: Add new template methods to ISourceControl. LabelSourceControl becomes LabelSourceControlSuccess and LabelSourceControlFailure. GetModifications becomes GetModifications and GetModificationsQuietPeriod. I don't particularly like this idea, but it would work. Idea 2: Pass in some sort of state to GetModifications and LabelSourceControl. I've done this with our local Allstate branch by passing in the IntegrationResult, and it works. The problem is that it violates encapsulation in that the source control classes may modify the build state. We could get around this by using a state pattern and giving the source control classes a read-only view of this state. Idea 3: Use events, similar to the way the publishers work. Source control classes register for events and act on them with needed. I envision some sort of state would be passed in as the event args. My preference would be 3, then 2, then 1 as a last resort. 3 is more major of a change. Your thoughts? Garrett |
|
From: <mik...@th...> - 2004-04-22 15:46:23
|
The following comment has been added to this issue:
Author:
Created: Thu, 22 Apr 2004 8:45 AM
Body:
Yeah, you are right, I mean that. If you look up the article at http://www.devx.com/opinion/Article/20826 you can see (and I think that's right), that the current scc providers don't force you to work with an uptodate build, so before you check in, you might not check the build on your own machine with the latest code, and that could cause ccnet build errors - which is good, but wouldn't it be better, if after popping up the successfull build baloon, there could me a question in the baloon asking whether to get the source code?
---------------------------------------------------------------------
View this comment:
http://jira.public.thoughtworks.org/browse/CCNET-64?page=comments#action_10096
---------------------------------------------------------------------
View the issue:
http://jira.public.thoughtworks.org/browse/CCNET-64
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CCNET-64
Summary: Getting sources after making successfull build
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: CruiseControl .NET
Components:
CCTray
Assignee:
Reporter:
Created: Thu, 22 Apr 2004 1:08 AM
Updated: Thu, 22 Apr 2004 8:45 AM
Description:
Let's see the problem of not getting synced with the code in the scc. The tray app may get the sources automatically after each successfull build, leaving the checked out or writable files. This would help letting all developers share the current and successfull sources.
---------------------------------------------------------------------
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: <mik...@th...> - 2004-04-22 15:42:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- 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 Versions: 0.4.2 Assignee: Reporter: Created: Thu, 22 Apr 2004 8:41 AM Updated: Thu, 22 Apr 2004 8:41 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 |