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
(1) |
3
|
4
|
5
(2) |
6
|
|
7
|
8
|
9
(1) |
10
(3) |
11
(1) |
12
|
13
|
|
14
(2) |
15
(4) |
16
(1) |
17
(2) |
18
(1) |
19
(1) |
20
|
|
21
(2) |
22
(2) |
23
|
24
|
25
|
26
(2) |
27
|
|
28
|
29
|
30
|
|
|
|
|
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-26 11:13:48
|
We have hundreds of checkins with no changes and comment 'force the build', 'use the force', 'force', 'f', 'aaargh!!!' etc... A quick look through ICruiseManager shows a method Run(string project, ISchedule schedule) which I thought might be useful for letting CCTray force a build for a specific project. However, the implementation in core.CruiseManager doesn't exist (empty method). I'd like to put this in. If anyone has any thoughts / advice / cautions to share, please let me know soon. Thanks all, Drew :) |
|
From: Drew N. <DN...@th...> - 2003-09-26 06:45:51
|
> Yeah - I'ven known about this for a while, sorry! http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-53 No problems. I went to update the Jira case with my progress, and figured I don't have an account on Truemesh... how can I get one, or do I already have one? > 1) Should we be able to include the output of publishers in the log? > 2) Should we be able to order publishers? > 3) If one publisher fails, should the others still run? Or does that depend on ordering? (If we have any?) 1 would be nice, see 3. 2 isn't explicitly possible, though it may be happening already (the publishers defined in config are registered as delegates for the event raised upon integration completion in the order that NetReflector loads them... this may be the config order... consequently, the event handlers probably run in the order specified in the file -- i've not checked this). 3 I've made modifications to Project / PublisherBase classes to support tolerance of failing publishers. If the publisher fails, an exception is logged, and processing continues as before. It would be great to include exception details in the Xml log, though this would require the Xml log publisher to be registered last. We're not too fussed about seeing why publishers failed on our project. Generally, it's the email publisher that bombs, because the Smtp server is too busy. In such cases, not getting an email doesn't matter too much as we're all running CCTray, which I've modified to play wav files when builds complete, depending upon success. We've got Homer Simpson welcoming in new builds :) My modifications include various other tidying up -- I'll check in once I'm back in the office (a few hours from now). Drew Noakes ThoughtWorks, Inc. UK dr...@th... Mike Roberts <mik...@th...> Sent by: ccn...@li... 22/09/2003 08:16 To: ccn...@li... cc: Subject: Re: [Ccnet-devel] Email publisher problem Noakes, Drew (Thoughtworks) wrote: >We're getting the following stacktrace fairly regularly on our project. It's not a CCNet problem directly (the SMTP server is too busy), but perhaps we could handle this a little better... > Yeah - I'ven known about this for a while, sorry! http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-53 >The output suggests the build was successful, but there's no record of it on the webpage. Is this exception stopping the build result from being logged? > So the web page only shows the result of the build, not the publishers, so nothing that 'goes bad' in the publishers shows up on the page. re: is the XMLLogger effected? I'm not sure - it depends how the event stuff works in the Project class. So, there's 3 (not independent) questions that come out of this: 1) Should we be able to include the output of publishers in the log? 2) Should we be able to order publishers? 3) If one publisher fails, should the others still run? Or does that depend on ordering? (If we have any?) This is starting to look like a workflow system so I'm going to shut up now. :) </in-joke> Mike ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Ccnet-devel mailing list Ccn...@li... https://lists.sourceforge.net/lists/listinfo/ccnet-devel |
|
From: Mike R. <mik...@th...> - 2003-09-22 13:17:23
|
Noakes, Drew (Thoughtworks) wrote: >We're getting the following stacktrace fairly regularly on our project. It's not a CCNet problem directly (the SMTP server is too busy), but perhaps we could handle this a little better... > Yeah - I'ven known about this for a while, sorry! http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-53 >The output suggests the build was successful, but there's no record of it on the webpage. Is this exception stopping the build result from being logged? > So the web page only shows the result of the build, not the publishers, so nothing that 'goes bad' in the publishers shows up on the page. re: is the XMLLogger effected? I'm not sure - it depends how the event stuff works in the Project class. So, there's 3 (not independent) questions that come out of this: 1) Should we be able to include the output of publishers in the log? 2) Should we be able to order publishers? 3) If one publisher fails, should the others still run? Or does that depend on ordering? (If we have any?) This is starting to look like a workflow system so I'm going to shut up now. :) </in-joke> Mike |
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-22 12:16:38
|
We're getting the following stacktrace fairly regularly on our project. = It's not a CCNet problem directly (the SMTP server is too busy), but = perhaps we could handle this a little better... The output suggests the build was successful, but there's no record of = it on the webpage. Is this exception stopping the build result from = being logged? Drew ---8<---cut here---8<--- [project: CAT] Starting new integration... [project: CAT] 30 Modifications detected... [project: CAT] Build Complete: Success [project: CAT] Exception occurred while running integration: = EmailPublisher exception: System.Web.HttpException: Could n ot access 'CDO.Message' object. ---> = System.Reflection.TargetInvocationException: Exception has been thrown = by the targe t of an invocation. ---> System.Runtime.InteropServices.COMException = (0x80040211): The message could not be sent to the SMTP server. The transport error code was 0x800ccc67. The server = response was 421 Server too busy. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags = invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags = invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] = namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at tw.ccnet.core.publishers.EmailGateway.Send(String from, String to, = String subject, String messageText) at tw.ccnet.core.publishers.EmailPublisher.SendMessage(String from, = String to, String subject, String message) System.Web.HttpException: Could not access 'CDO.Message' object. ---> = System.Reflection.TargetInvocationException: Excep tion has been thrown by the target of an invocation. ---> = System.Runtime.InteropServices.COMException (0x80040211): The message could not be sent to the SMTP server. The transport error code = was 0x800ccc67. The server response was 421 Serve r too busy. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags = invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags = invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] = namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at tw.ccnet.core.publishers.EmailGateway.Send(String from, String to, = String subject, String messageText) at tw.ccnet.core.publishers.EmailPublisher.SendMessage(String from, = String to, String subject, String message) [project: CAT] Project threw an exception: = tw.ccnet.core.CruiseControlException: EmailPublisher exception: = System.Web.Ht tpException: Could not access 'CDO.Message' object. ---> = System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> = System.Runtime.InteropServices.COMException (0x80040211): The message = could not be sent to the SMTP server. The transport error code was = 0x800ccc67. The server response was 421 Server too busy. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags = invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags = invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] = namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at tw.ccnet.core.publishers.EmailGateway.Send(String from, String to, = String subject, String messageText) at tw.ccnet.core.publishers.EmailPublisher.SendMessage(String from, = String to, String subject, String message) ---> S ystem.Web.HttpException: Could not access 'CDO.Message' object. ---> = System.Reflection.TargetInvocationException: Except ion has been thrown by the target of an invocation. ---> = System.Runtime.InteropServices.COMException (0x80040211): The m essage could not be sent to the SMTP server. The transport error code = was 0x800ccc67. The server response was 421 Server too busy. --- End of inner exception stack trace --- at System.RuntimeType.InvokeDispMethod(String name, BindingFlags = invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) at System.RuntimeType.InvokeMember(String name, BindingFlags = invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] = namedParameters) at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) --- End of inner exception stack trace --- at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, = String methodName, Object[] args) at System.Web.Mail.CdoSysHelper.Send(MailMessage message) at System.Web.Mail.SmtpMail.Send(MailMessage message) at tw.ccnet.core.publishers.EmailGateway.Send(String from, String to, = String subject, String messageText) at tw.ccnet.core.publishers.EmailPublisher.SendMessage(String from, = String to, String subject, String message) --- End of inner exception stack trace --- at tw.ccnet.core.publishers.EmailPublisher.SendMessage(String from, = String to, String subject, String message) at tw.ccnet.core.publishers.EmailPublisher.Publish(Object source, = IntegrationResult result) at tw.ccnet.core.IntegrationEventHandler.Invoke(Object sender, = IntegrationResult result) at tw.ccnet.core.Project.RaiseIntegrationEvent(IntegrationResult = result) at tw.ccnet.core.Project.PostBuild() at tw.ccnet.core.Project.Run(Boolean forceBuild) at tw.ccnet.core.schedule.Scheduler.Run() [project: CAT] Sleeping for 00:05:00 |
|
From: Owen R. <OR...@th...> - 2003-09-21 15:38:38
|
hey jr, your patch is now committed. cheers, owen. --- R. Owen Rogers ThoughtWorks Ltd ThoughtWorks - Deliver with passion! |---------+----------------------------> | | Jonathan T | | | Rasmusson | | | | | | 20/09/2003 19:03 | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Mike Roberts/UK/ThoughtWorks@ThoughtWorks | | cc: Owen Rogers/Canada/ThoughtWorks@ThoughtWorks | | Subject: PVCS Bug Fix | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hi Mike, Included is another bug fix for CC.NET PVCS. The wrong date was been displayed in the build results page after a PVCS build. The fix was to parse for a differnent string. else if (line.StartsWith("Checked in:")){ instead of else if (line.StartsWith("Last modified:")){ Last modified could have been way in the past (not reflective of the last time a change was made to file). Only one file (and respective test) are effected. Cheers JR |
|
From: Owen R. <OR...@th...> - 2003-09-21 15:34:36
|
whoops, this is my bad. i had fixed this originally on another machine and then forgotten to check it back into cvs. should be in there now. the problem is related to machines that don't have the US region installed are unable to parse US-style dates (ah, internationalisation). i wanted to be able to simulate this before checking in the fix (the original fix was a bit of a hack). i was able to do this by going into regional settings and removing the US locale. anyway, should work now. cheers, owen. --- R. Owen Rogers ThoughtWorks Ltd ThoughtWorks - Deliver with passion! |---------+---------------------------------------> | | Michael L Royle | | | <ML...@th...> | | | Sent by: | | | ccn...@li...| | | ceforge.net | | | | | | | | | 19/09/2003 10:11 | |---------+---------------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: ccn...@li... | | cc: | | Subject: [Ccnet-devel] Test failures in GMT | >--------------------------------------------------------------------------------------------------------------------------------------------------| I was running the current set of tests in London and 6 failed. They all seem to be date related. I've included the failure messages in the attachment. Mike (See attached file: ccneterrors.txt) |
|
From: Michael L R. <ML...@th...> - 2003-09-19 19:45:26
|
I was running the current set of tests in London and 6 failed. They all seem to be date related. I've included the failure messages in the attachment. Mike (See attached file: ccneterrors.txt) |
|
From: Mike R. <mik...@th...> - 2003-09-18 03:27:15
|
Arjen Poutsma wrote: >Hi, > >The attached patch for Cvs.cs allows one to restrict modifications to >specific users. It uses the '-w' option of the 'cvs log' command. You >can use it like so: > > Hi Arjen, Sorry for the delay in putting this in. Its now applied, as of build 30. If you get the chance to update the unit test, that would be ace. Just download the build 30 source and you should be good to go. (its at http://ccnetlive.thoughtworks.com/CCNet-builds/30/CruiseControl.NET.source.zip) Cheers, Mike -- Mike Roberts http://mikeroberts.thoughtworks.net/ |
|
From: Mike R. <mi...@th...> - 2003-09-17 15:00:01
|
Thanks JR - I included this in some documentation updates I just uploaded. Everyone - I changed the doc strucure a little and started showing where we are missing docs. If anyone fancies being a scribe, please go ahead. ;) Once there's a bit more content I'll update the CCNetLive to automatically push doc updates to the CCNet website. Mike Jonathan T Rasmusson wrote: > > Hi all, > > Been doing some PVCS work lately and wanted to post a working > ccnet.config example along with the cruise.build file. Thanks to > Jerimahs earlier posts regarding cc.net and PVCS integration. > > I have tried to add comments and explainations where necessary. > The only thing I am not sure how to do yet is an incremental update > from PVCS (currently I am just deleteing the entire project and getting > it out again). If anyone knows how to do an incremental update in PVCS > please post here. > > Also, I noticed PVCS does not always build with new files are added or > deleted to the repository. CC detects the modification, but for some > reason my build does not kick off. > > I will investigate and post back later. |
|
From: Jonathan T R. <JRa...@th...> - 2003-09-17 14:01:32
|
Hi all, Been doing some PVCS work lately and wanted to post a working ccnet.config example along with the cruise.build file. Thanks to Jerimahs earlier posts regarding cc.net and PVCS integration. I have tried to add comments and explainations where necessary. The only thing I am not sure how to do yet is an incremental update from PVCS (currently I am just deleteing the entire project and getting it out again). If anyone knows how to do an incremental update in PVCS please post here. Also, I noticed PVCS does not always build with new files are added or deleted to the repository. CC detects the modification, but for some reason my build does not kick off. I will investigate and post back later. Hope this helps Cheers JR ccnet.config ============ <cruisecontrol> <project name="Project1"> <schedule type="schedule" timeout="10000"/> <modificationDelay>10000</modificationDelay> <sourcecontrol type="pvcs"> <executable>C:\Program Files\PVCS\vm\win32\bin\pcli.exe</executable> <!-- you can read project path from PVCS GUI --> <!-- its the absolute dir in brackets after the project data base name --> <!-- i.e. <project>-pr'C:\somedir\pvcsrepos'</project> --> <project>-pr'type path to PVCS repository'</project> <!-- type the relative path (proceeded with a slash) to the subproject --> <!-- i.e. <subproject>/project1/Payroll</subproject> --> <subproject>/someProject</subproject> </sourcecontrol> <build type="nant"> <executable>C:\apps\nant-0.8.3.50100\bin\nant.exe</executable> <!-- this is the path to the builder directory where we installed cc.net --> <!-- copy the cruise.build file into this directory --> <baseDirectory>C:\someDir\builder</baseDirectory> <buildArgs>-logger:NAnt.Core.XmlLogger -D:pvcs.executable="C:\Program Files\PVCS\vm\win32\bin\pcli.exe"</buildArgs> <buildFile>cruise.build</buildFile> <targetList> <target>run</target> </targetList> <buildTimeout>100000</buildTimeout> </build> <publishers> <email from="bui...@my..." mailhost="host.net" includeDetails="TRUE"> <projectUrl>http://localhost/ccnet</projectUrl> <users> <user name="BuildGuru" group="buildmaster" address="bui...@my..."/> <user name="JoeDeveloper" group="developers" address="fo...@ba..."/> </users> <groups> <group name="developers" notification="change"/> <group name="buildmaster" notification="always"/> </groups> </email> <xmllogger> <logDir>..\website\log</logDir> </xmllogger> </publishers> </project> </cruisecontrol> cruise.build ============ <project name="ccnetlaunch" default="run"> <target name="run" depends="update,build"/> <!-- base.dir is the dir where cc will do its check outs and builds --> <!-- i.e. <property name="base.dir" value="C:\someDir\cc-code"/> --> <property name="base.dir" value="cc.net checkouts and build dir"/> <target name="update"> <delete> <fileset> <includes name="${base.dir}\**\*" /> </fileset> </delete> <!-- <exec basedir="${base.dir}" program="${pvcs.executable}" commandline=' get -pr"our pvcs directory root" -a${base.dir} -o -z /' /> --> <!-- pvcs.executable was set for us in the ccnet.config file --> <exec basedir="${base.dir}" program="${pvcs.executable}" commandline=' get -pr"C:\somedir\pvcsrepos" -a${base.dir} -o -z /' /> </target> <target name="build"> <!-- point to our project build file in our cc.net build directory --> <!-- <nant buildfile="${base.dir}\project1\Payroll\PayrollApp\payroll.build" /> --> <nant buildfile="${base.dir}\subproject name\project build file" /> </target> </project> |
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-16 08:55:16
|
Good stuff Mike!
I'm trying to update modifications.xsl to show mods like this:
noakd1 - A comment for my checkin
edit SomeFile.cs
edit AnotherFile.cs
add NewFile.cs
guox6 - My checkin will eat your chicken
edit Pumpkernickel.cs
delete Unloved.cs
...but I can't work out the grouping functionality in Xsl. There's =
xsl:for-each-group in Xsl 2.0, but it seems that .NET won't support it. =
The other approach (Muenchian method) looks damn complicated. I'm not =
very experienced with Xsl; is there anyone out there who can give me a =
pointer?
Drew
-----Original Message-----
From: Mike Roberts [mailto:mi...@th...]
Sent: 15 September 2003 22:32
To: ccn...@li...
Subject: [Ccnet-devel] Plugins for Web App (Requires web.config update!)
Hi,
I've added some plugin-ability to the webapp, and changed the way we=20
link to some of the pages to use this new functionality.
We now have a section group in web.config that looks as follows:
<CCNet>
<projectPlugins>
<plugin linkText=3D"project stats" =
linkUrl=3D"Statistics.aspx" />
</projectPlugins>
<buildPlugins>
<plugin linkText=3D"test details" =
linkUrl=3D"Tests.aspx?/log=3D" />
<plugin linkText=3D"test timing"=20
linkUrl=3D"TestTiming.aspx?/log=3D" />
<plugin linkText=3D"original log" linkUrl=3D"log/" />
</buildPlugins>
<xslFiles>
<file name=3D"xsl\header.xsl"/>
<file name=3D"xsl\compile.xsl"/>
<file name=3D"xsl\unittests.xsl"/>
<file name=3D"xsl\fit.xsl"/>
<file name=3D"xsl\modifications.xsl"/>
</xslFiles>
</CCNet>
'project plugins' show the same content, whatever build you are on (and=20
appear in the top menu bar). 'build plugins' show different content for=20
different builds (and appear in the 2nd menu bar)
In theory therefore, if you want to add custom metrics (as an example)=20
to your app now (either per-project, or per-build) you can just write=20
any new page, put it in the web dir, and add a plugin line.
I feel that maybe we may need something more complicated this in the=20
future, but I can't think of it right now. :)
NB - You need to update your web.config file!!!
If you want to try this out, use the new 'test-web' target in the build=20
and add the 'deployed\web' folder that's created as a Virtual Directory=20
on your machine.
Mike
--=20
Mike Roberts
http://mikeroberts.thoughtworks.net/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: Mike R. <mi...@th...> - 2003-09-15 21:32:42
|
Hi,
I've added some plugin-ability to the webapp, and changed the way we
link to some of the pages to use this new functionality.
We now have a section group in web.config that looks as follows:
<CCNet>
<projectPlugins>
<plugin linkText="project stats" linkUrl="Statistics.aspx" />
</projectPlugins>
<buildPlugins>
<plugin linkText="test details" linkUrl="Tests.aspx?/log=" />
<plugin linkText="test timing"
linkUrl="TestTiming.aspx?/log=" />
<plugin linkText="original log" linkUrl="log/" />
</buildPlugins>
<xslFiles>
<file name="xsl\header.xsl"/>
<file name="xsl\compile.xsl"/>
<file name="xsl\unittests.xsl"/>
<file name="xsl\fit.xsl"/>
<file name="xsl\modifications.xsl"/>
</xslFiles>
</CCNet>
'project plugins' show the same content, whatever build you are on (and
appear in the top menu bar). 'build plugins' show different content for
different builds (and appear in the 2nd menu bar)
In theory therefore, if you want to add custom metrics (as an example)
to your app now (either per-project, or per-build) you can just write
any new page, put it in the web dir, and add a plugin line.
I feel that maybe we may need something more complicated this in the
future, but I can't think of it right now. :)
NB - You need to update your web.config file!!!
If you want to try this out, use the new 'test-web' target in the build
and add the 'deployed\web' folder that's created as a Virtual Directory
on your machine.
Mike
--
Mike Roberts
http://mikeroberts.thoughtworks.net/
|
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-15 16:54:47
|
Hi Bill, We're generally getting successful builds through CCNET. We have a = custom task (checkbuildresult) which parses the piped devenv.exe stdout = file, checking for the return code. If the return code is 1, then the = checkbuildresult task throws the appropriate BuildException. Is there = an easier way to use devenv in NAnt, to avoid this custom task (which = we've written btw). A situation that arises occasionally is this: the build passes (as far = as, CCNET sends a success email etc) but the compilation failed. I'll = post if we find the cause of this (and it's of general interest). The (possibly) important point from my previous mail is that our CCNET = output conforms to the schema expected by the old (pre-patched) Xsl = file. I wonder why your <buildresult> element is at the same level as = <build>. Cheers, Drew -----Original Message----- From: William E Caputo [mailto:WEC...@th...] Sent: 15 September 2003 16:55 To: Noakes, Drew (Thoughtworks) Cc: ccn...@li...; ccn...@li...; Guo, Xiao (Contractor) Subject: RE: [Ccnet-devel] [PATCH] issue resolved with csc compile errors Hi Drew, I don't think your problem is the same as mine. Looking over the log = file, your nant output doesn't have any message elements that contain compiler output (mine did, just in the wrong part of the tree). The XSLT looks = for <message> elements containing either the words 'error' or 'warning' -- = your log file has none of this csc output. I suspect something's up with your exec call to devenv. (from your log): <message> <![CDATA[ I:\ccnet-sourceforge\projects\CAT\checkout\src\NAnt.build(31,4): External Program Failed: devenv (return code was 1) ]]> </message> What happens if you run the devenv command by itself on the command-line = in the same directory as the build would run? Best, Bill William E. Caputo ThoughtWorks, Inc. -------- A Plan is a list of things that don't happen |
|
From: William E C. <WEC...@th...> - 2003-09-15 15:55:46
|
Hi Drew,
I don't think your problem is the same as mine. Looking over the log file,
your nant output doesn't have any message elements that contain compiler
output (mine did, just in the wrong part of the tree). The XSLT looks for
<message> elements containing either the words 'error' or 'warning' -- your
log file has none of this csc output.
I suspect something's up with your exec call to devenv. (from your log):
<message>
<![CDATA[
I:\ccnet-sourceforge\projects\CAT\checkout\src\NAnt.build(31,4):
External Program Failed: devenv (return code was 1)
]]>
</message>
What happens if you run the devenv command by itself on the command-line in
the same directory as the build would run?
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
"Noakes, Drew
(Thoughtworks)" To: "William E Caputo" <WEC...@th...>,
<no...@bp...> <ccn...@li...>
Sent by: cc: "Guo, Xiao (Contractor)" <gu...@bp...>
ccn...@li... Subject: RE: [Ccnet-devel] [PATCH] issue resolved with csc compile errors
ceforge.net
09/15/2003 04:08 AM
Hi William,
I've tried your patch out, in the hope that it may fix the problem you
described and that we've been seeing. Take a peek at the attached Xml file
and you'll see that the schema matches the expected schema (i.e. the one
intended to be used without your patch).
We in fact get:
<cruisecontrol>
<modifications/>
<build>
<buildresults/>
</build>
<test-results/>
</cruisecontrol>
Perhaps something else is happening to cause different schemas on different
configurations? We're running a very recent build from Cvs head. I've
also attached our NAnt scripts -- in case they're contributing to this
variation.
Drew
(Note that I reformatted the logfile Xml a little for easier viewing of the
schema)
-----Original Message-----
From: William E Caputo [mailto:WEC...@th...]
Sent: 14 September 2003 17:30
To: ccn...@li...
Subject: [Ccnet-devel] [PATCH] issue resolved with csc compile errors
Hi All,
I resolved an issue at a client site where the csc compiler errors/warnings
were not showing up on the build page. Here are my notes and my workaround
(still don't know why its happening). Also I have attached a patch for
compile.xsl that corrects this issue (and is backward compatible) and also
factors out some duplication in that file. So, there's really two changes
in that patch, whoever considers this for inclusion should consider the
changes separately (i.e. you may not want the different path, but you might
consider removing the duplication).
Note/Workaround:
Compiler errors/warnings were not showing up on the build page. Originally
the ccnet.config file didn't have the NAnt XmlLogger specified as a command
line argument to nant, but even after doing so, the buildresults were in
the wrong place.
the ccnet build log has a structure like this:
<cruisecontrol>
<modifications/>
<build/>
<test-results/>
</cruisecontrol>
<buildresults> is the root element for NAnt's xml output
If you look at compile.xsl it expects this element to be a child of
<build>:
<cruisecontrol>
<modifications/>
<build>
<buildresults/>
</build>
<test-results/>
</cruisecontrol>
and will match using this xpath expression:
/cruisecontrol/build/buildresults//message[contains(text(), 'error')]
(there is another for 'warning')
However in our file, <buildresults> is showing up as a peer of <build>:
<cruisecontrol>
<modifications/>
<build/>
<buildresults/>
<test-results/>
</cruisecontrol>
By changing the xpath expression to:
/cruisecontrol//buildresults//message[contains(text(), 'error')]
Our files match.
One other weird thing about this issue: *sometimes* (I haven't figured out
under what conditions) the buildresults element is correctly located as a
child of the build element. That made me think there was something flaky
about the configuration/installation, but I couldn't find anything.
Attached is a patch against the latest source from cvs. I used unidiff
format. If there is a preferred format for diffs, please let me know -- the
ccnet online project details only suggest using eclipse.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
(See attached file: compile_xsl.patch)
|
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-15 09:12:30
|
Hi William,
I've tried your patch out, in the hope that it may fix the problem you =
described and that we've been seeing. Take a peek at the attached Xml =
file and you'll see that the schema matches the expected schema (i.e. =
the one intended to be used without your patch).
We in fact get:
<cruisecontrol>
<modifications/>
<build>
<buildresults/>
</build>
<test-results/>
</cruisecontrol>
Perhaps something else is happening to cause different schemas on =
different configurations? We're running a very recent build from Cvs =
head. I've also attached our NAnt scripts -- in case they're =
contributing to this variation.
Drew
(Note that I reformatted the logfile Xml a little for easier viewing of =
the schema)
-----Original Message-----
From: William E Caputo [mailto:WEC...@th...]
Sent: 14 September 2003 17:30
To: ccn...@li...
Subject: [Ccnet-devel] [PATCH] issue resolved with csc compile errors
Hi All,
I resolved an issue at a client site where the csc compiler =
errors/warnings
were not showing up on the build page. Here are my notes and my =
workaround
(still don't know why its happening). Also I have attached a patch for
compile.xsl that corrects this issue (and is backward compatible) and =
also
factors out some duplication in that file. So, there's really two =
changes
in that patch, whoever considers this for inclusion should consider the
changes separately (i.e. you may not want the different path, but you =
might
consider removing the duplication).
Note/Workaround:
Compiler errors/warnings were not showing up on the build page. =
Originally
the ccnet.config file didn't have the NAnt XmlLogger specified as a =
command
line argument to nant, but even after doing so, the buildresults were in
the wrong place.
the ccnet build log has a structure like this:
<cruisecontrol>
<modifications/>
<build/>
<test-results/>
</cruisecontrol>
<buildresults> is the root element for NAnt's xml output
If you look at compile.xsl it expects this element to be a child of
<build>:
<cruisecontrol>
<modifications/>
<build>
<buildresults/>
</build>
<test-results/>
</cruisecontrol>
and will match using this xpath expression:
/cruisecontrol/build/buildresults//message[contains(text(), 'error')]
(there is another for 'warning')
However in our file, <buildresults> is showing up as a peer of <build>:
<cruisecontrol>
<modifications/>
<build/>
<buildresults/>
<test-results/>
</cruisecontrol>
By changing the xpath expression to:
/cruisecontrol//buildresults//message[contains(text(), 'error')]
Our files match.
One other weird thing about this issue: *sometimes* (I haven't figured =
out
under what conditions) the buildresults element is correctly located as =
a
child of the build element. That made me think there was something flaky
about the configuration/installation, but I couldn't find anything.
Attached is a patch against the latest source from cvs. I used unidiff
format. If there is a preferred format for diffs, please let me know -- =
the
ccnet online project details only suggest using eclipse.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
(See attached file: compile_xsl.patch)
|
|
From: William E C. <WEC...@th...> - 2003-09-14 16:30:38
|
One of our clients ran into a problem trying to install the ccnet as a service. Running installutil.exe against ccnet.service.exe resulted in the following error: "No public installers with the RunInstallerAttribute.Yes attribute could be found in the d:\ccnet\builder\ccnet.service.exe assembly." This was a real PITA to find, but its really easy to correct. The problem occurs when you run the installutil.exe located in the 1.0 framework bundle against a service compiled with the 1.1 framework compiler. Changing the path on the box from finding the installutil.exe in: C:\WINNT\Microsoft.NET\Framework\v1.0.3705 to: C:\WINNT\Microsoft.NET\Framework\v1.1.4322 ( for the machine in question) solved the problem. Best, Bill William E. Caputo ThoughtWorks, Inc. -------- A Plan is a list of things that don't happen |
|
From: William E C. <WEC...@th...> - 2003-09-14 16:30:38
|
Hi All,
I resolved an issue at a client site where the csc compiler errors/warnings
were not showing up on the build page. Here are my notes and my workaround
(still don't know why its happening). Also I have attached a patch for
compile.xsl that corrects this issue (and is backward compatible) and also
factors out some duplication in that file. So, there's really two changes
in that patch, whoever considers this for inclusion should consider the
changes separately (i.e. you may not want the different path, but you might
consider removing the duplication).
Note/Workaround:
Compiler errors/warnings were not showing up on the build page. Originally
the ccnet.config file didn't have the NAnt XmlLogger specified as a command
line argument to nant, but even after doing so, the buildresults were in
the wrong place.
the ccnet build log has a structure like this:
<cruisecontrol>
<modifications/>
<build/>
<test-results/>
</cruisecontrol>
<buildresults> is the root element for NAnt's xml output
If you look at compile.xsl it expects this element to be a child of
<build>:
<cruisecontrol>
<modifications/>
<build>
<buildresults/>
</build>
<test-results/>
</cruisecontrol>
and will match using this xpath expression:
/cruisecontrol/build/buildresults//message[contains(text(), 'error')]
(there is another for 'warning')
However in our file, <buildresults> is showing up as a peer of <build>:
<cruisecontrol>
<modifications/>
<build/>
<buildresults/>
<test-results/>
</cruisecontrol>
By changing the xpath expression to:
/cruisecontrol//buildresults//message[contains(text(), 'error')]
Our files match.
One other weird thing about this issue: *sometimes* (I haven't figured out
under what conditions) the buildresults element is correctly located as a
child of the build element. That made me think there was something flaky
about the configuration/installation, but I couldn't find anything.
Attached is a patch against the latest source from cvs. I used unidiff
format. If there is a preferred format for diffs, please let me know -- the
ccnet online project details only suggest using eclipse.
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
(See attached file: compile_xsl.patch)
|
|
From: Michael C T. <MC...@th...> - 2003-09-10 22:12:10
|
There used to be a bit of code in there using a dll import that got around
this. Not sure if it is still thre or not.
ThoughtWorks, where being meta-cognitive is something worth thinking
about.
Mike Roberts <mi...@th...>
Sent by: ccn...@li...
09/10/2003 05:06 PM
To: ccn...@li...
cc:
Subject: Re: [Ccnet-devel] Updates to CCTray project
Noakes, Drew (Thoughtworks) wrote:
>A bug that I haven't worked out how to fix is the presense of an icon
while ALT_TABbing between apps. The invisible form doesn't appear on the
taskbar, but can be alt tabbed to, and then won't go away unless app is
closed.
>
Is this a new bug introduced with the new features? I'm a bit worried
committing stuff that breaks something that worked before. That said,
its not a critical part of the app, and the new features look cool, so
I'm not too worried. :)
Mike
--
Mike Roberts
http://mikeroberts.thoughtworks.net/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel
|
|
From: Mike R. <mi...@th...> - 2003-09-10 22:07:32
|
Noakes, Drew (Thoughtworks) wrote: >A bug that I haven't worked out how to fix is the presense of an icon while ALT_TABbing between apps. The invisible form doesn't appear on the taskbar, but can be alt tabbed to, and then won't go away unless app is closed. > Is this a new bug introduced with the new features? I'm a bit worried committing stuff that breaks something that worked before. That said, its not a critical part of the app, and the new features look cool, so I'm not too worried. :) Mike -- Mike Roberts http://mikeroberts.thoughtworks.net/ |
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-10 12:59:47
|
Hi, I've updated the CCTray app. - It displays a balloon pop-up after each build with details of status - It no longer pauses for ages before displaying context menu when tray = icon right-clicked and no connection exists - Exception details are displayed in the tooltip text - Monitoring code is refactored out to reusable component, with client = code handling events A bug that I haven't worked out how to fix is the presense of an icon = while ALT_TABbing between apps. The invisible form doesn't appear on = the taskbar, but can be alt tabbed to, and then won't go away unless app = is closed. Code and binary attached. Make sure you update the .config file to = point at your server. I don't have commit access, so can someone please merge this in. Cheers, Drew <<CCTray.zip>>=20 |
|
From: Mike R. <MRo...@th...> - 2003-09-09 04:15:35
|
Hi there, Just finished my vacation - I shall try and have a look back over stuff that's happened recently over the next week or so, but if anyone has anything urgent please shout. :) Updates today - Fixed the 'bad state file screws us up completely' bug by ignoring the output field when serializing state (http://jira.truemesh.com/secure/ViewIssue.jspa?key=CC-56) - Since NAnt 0.8.3 and NUnit 2.1 have now both gone final I've updated the source tree to use them (so CVS'ers - you'll probably want to be on a fat connection next time you update) - Committed a PVCS fix supplied by JR (thx JR!) Mike -- Mike Roberts http://mikeroberts.thoughtworks.net/ |
|
From: Mike R. <mi...@th...> - 2003-09-05 16:15:16
|
Applied - thx. Noakes, Drew (Thoughtworks) wrote: >I've put 16x16 pixel icons in the cctray *.ico files, rather than scale the 32x32 pixel versions down. > |
|
From: Mike R. <mi...@th...> - 2003-09-05 16:10:41
|
Applied - thanks guys! :) Mike Noakes, Drew (Thoughtworks) wrote: >Xiao and I have just migrated our team's CCNET installation to the CVS head revision. In doing so, we found and fixed a bug in the parsing of p4.exe output. > >The previous implementation assumes comments start with 'text: ', where that whitespace is three spaces. In fact, the whitespace is a single space, and then a tab character. Consequently, the tests would pass, but no checkin comments were making the build page. > >I've piped p4.exe's output to a file, and attached it for your reference (character for character). The attached .zip file should be unzipped into the ccnet/core/sourcecontrol folder. It contains updated tests, and the fixed p4 implementation. We've also commented the implementation a little. > >Regards, > >Drew & Xiao > > <<sample-p4-output.txt>> <<sourcecontrol.ZIP>> > > |
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-02 09:29:54
|
I've put 16x16 pixel icons in the cctray *.ico files, rather than scale = the 32x32 pixel versions down. The 32x32 pixel versions don't appear to = be in use anywhere. This little app is very useful! The updated files are attached. Can someone include my sf username as a committer? (drewnoakes) Drew <<Red.ico>> <<Green.ico>> <<Gray.ico>>=20 |
|
From: Noakes, D. (Thoughtworks) <no...@bp...> - 2003-09-01 16:41:12
|
Xiao and I have just migrated our team's CCNET installation to the CVS = head revision. In doing so, we found and fixed a bug in the parsing of = p4.exe output. The previous implementation assumes comments start with 'text: ', = where that whitespace is three spaces. In fact, the whitespace is a = single space, and then a tab character. Consequently, the tests would = pass, but no checkin comments were making the build page. I've piped p4.exe's output to a file, and attached it for your reference = (character for character). The attached .zip file should be unzipped = into the ccnet/core/sourcecontrol folder. It contains updated tests, = and the fixed p4 implementation. We've also commented the = implementation a little. Regards, Drew & Xiao =20 <<sample-p4-output.txt>> <<sourcecontrol.ZIP>>=20 |
1 message has been excluded from this view by a project administrator.