ccnet-devel Mailing List for CruiseControl.NET

I will be out of the office starting  10/27/2003 and will not return until
10/31/2003.

Call on cell phone if urgent - 07966 289591.  I may not answer but will
pick up messages at least daily.

I will be out of the office starting  10/27/2003 and will not return until
11/03/2003.

I will not have access to email until Friday 10/31.  For immediate Notes
support contact IS at 8600.  Please call my cell phone regarding urgent
matters. Thanks.

I will be out of the office starting  27/10/2003 and will not return until
03/11/2003.

I will respond to your message when I return.

I will be out of the office starting  10/15/2003 and will not return until
11/24/2003.

I will respond to your message when I return.

Thanks Andrew,

Forwarding your comments to the mailing list...


----- Forwarded by Drew Noakes/UK/ThoughtWorks on 29/10/2003 17:25 -----
|---------+---------------------------->
|         |           "Greiner, Andrew"|
|         |           <andrew.greiner@t|
|         |           homson.com>      |
|         |                            |
|         |           29/10/2003 16:57 |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       "'Drew Noakes'" <DN...@th...>                                                                   |
  |       cc:       "Huang, Yanli" <yan...@th...>                                                                     |
  |       Subject:  RE: [Ccnet-user] CruiseControl.NET Development Day                                                           |
  >------------------------------------------------------------------------------------------------------------------------------|




I know that some of the development teams here have been screaming for the
VSS get latest to be reviewed. Currently the history command in CCNet is
creating a command that generates a date time string that does not work in
version 6.0d of VSS. I believe that the spaces in between the time and the
PM and AM are causing problems (11:00:00 PM~ 10:00:00 AM). If that has
already been addressed then please forgive my lateness in requesting this.
I
know this is not a feature, but it would be good if someone could review
this problem.

Thanks

Andrew

-----Original Message-----
From: Drew Noakes [mailto:DN...@th...]
Sent: Wednesday, October 29, 2003 6:11 AM
To: ccn...@li...; ccn...@li...
Subject: [Ccnet-user] CruiseControl.NET Development Day






This Saturday, a group of people are getting together in London to plan and
perform the highest-priority updates to CCNet.   To help us prioritise,
please take the time to vote for the features you'd hate to go without.
Here's a list of ideas to get started -- if something's missing, add it.

In no particular order:

- faster web pages
- prettier web pages (colours, layout, grouping of modifications)
- additional source-control support
- proper css support for html emails (they look odd right now)
- gui tool for configuration (rather than editing xml file by hand)
- better configuration documentation
- better developer documentation
- a way for ccnet to perform checkout (currently, this must be done by the
user's build script)
- 'original log' button on webpage shouldn't require log files to be within
http root on server
- new NAnt task to support parsing of devenv.exe output (this exists, but
hasn't been integrated)
- timeout for build process (i.e. if build doesn't complete within 'n'
minutes, consider it 'hung' and kill process)
- feature '...'

For these points, please explain what could be fixed or improved:

- installation
- multi-project support
- running ccnet as a windows service
- bug '...'

If you'd like to participate in this development fest, drop me a line.

(I've just seen Mike's email -- please factor his points into your
thoughts)

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Ccnet-user mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-user

Hi Jeremiah,

Thanks for your contribution.  You don't fancy popping over to London for
the day on Saturday, do you :)

I've copied your votes to the development list.

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...




|---------+------------------------------>
|         |           "Jeremiah          |
|         |           Wittevrongel"      |
|         |           <Jeremiah_Wittevron|
|         |           ge...@cp...>        |
|         |                              |
|         |           29/10/2003 15:35   |
|         |                              |
|---------+------------------------------>
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       "Drew Noakes" <DN...@th...>                                                                     |
  |       cc:                                                                                                                    |
  |       Subject:  RE: [Ccnet-user] CruiseControl.NET Development Day                                                           |
  >------------------------------------------------------------------------------------------------------------------------------|




Drew, here are my votes:
1) configurable timeout for source control / change detection.  Using PVCS
over a somewhat slow corporate network, we've had to tweak the ccnet source
and rebuild, since the hardcoded timeout of 30 seconds is insufficient (we
need 5-7 minutes).
2) multiple project support in the web app
3) 'original log' not working when logs not within http root
4) More user and developer documentation - for instance, the fact that
ccnet sets ${label-to-apply} is not documented very well.

and as a wishlist item:
5) nant tasks for talking to PVCS

Unfortunately, I don't have enough leeway in my current project timelines
at work to do #5, otherwise It would probably already be done.
Regards,

-- Jeremiah Wittevrongel
IS Analyst, Canadian Pacific Railway
jer...@cp...

We are using CCNET here at Thomson in New York, but I must confess I 
didn't set it up. I have set up CC for Java before, and it was a pain.

I would say that the problem with most open source projects is that they 
are built by developers (I'm including myself in this accusation also) and 
developers assume because they understand it, it is easy to understand in 
general. So, I would vote for either very explicit documentation or an 
extremely intuitive gui for setup and admin, preferably the both.

All best,
John Perkins

This Saturday, a group of people are getting together in London to plan and
perform the highest-priority updates to CCNet.   To help us prioritise,
please take the time to vote for the features you'd hate to go without.
Here's a list of ideas to get started -- if something's missing, add it.

In no particular order:

- faster web pages
- prettier web pages (colours, layout, grouping of modifications)
- additional source-control support
- proper css support for html emails (they look odd right now)
- gui tool for configuration (rather than editing xml file by hand)
- better configuration documentation
- better developer documentation
- a way for ccnet to perform checkout (currently, this must be done by the
user's build script)
- 'original log' button on webpage shouldn't require log files to be within
http root on server
- new NAnt task to support parsing of devenv.exe output (this exists, but
hasn't been integrated)
- timeout for build process (i.e. if build doesn't complete within 'n'
minutes, consider it 'hung' and kill process)
- feature '...'

For these points, please explain what could be fixed or improved:

- installation
- multi-project support
- running ccnet as a windows service
- bug '...'

If you'd like to participate in this development fest, drop me a line.

(I've just seen Mike's email -- please factor his points into your
thoughts)

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...

Drew is arranging a 'CCNet Dev Day' this weekend in London, which I 
think will be publicised separately. It seems an appropriate time for me 
to bring up a priority list of things on my mind at the moment though.

Highest priority

- Improve documentation enough for 0.4 release, and generate release notes
- Get email working on CCNetLive
- 0.4 release. :)
- Check service working (e.g. problem with remoting?) , document
- Docs for CCTray
- Another release for this, if 0.4 not already released

Lower priority

- Security for management (e.g. management functions that have side 
effects should be authenticated / authorised)
- Recode the CruiseControl / Project stuff for generic projects / 
simpler design.
- Documentation improvements, e.g. more examples (CC and NAnt) for all 
supported SCM systems
- Allowing Dashboard and CCTray to communicate with web service, not 
just remoting, for management service
- Adding a section to the WebApp to query management service (to display 
the same data the dashboard does)
- Allowing the Management service clients to support multi-project servers
- Setup CCNetLive for CCTray over webservice access.
- Setup CCNetLive for NetReflector and SiteMesh
- SVN integration
- Namespace refactoring
- .
- .
- 0.5 release. :)

Mike

Mike Roberts:
>1 - I don't think of the 'labeller' within CCNet as something which 
>actually applies a label, more of a 'build number creator'. As such, I 
>would only use the default one.

Yes that's probably a better description of what it does, but regardless, 
the default labeller creates a label that is not truly compatible with VSS 
(VSS should not use plain numeric labels, or labels that begin with the 
letter "L"). So we have to either modify the default Labeller to allow a 
prefix, or create a new label-generator that has this behavior, Yes?

>2 - The CCNet NAnt builder passes a property into the NAnt script called 
>'label-to-apply' - this is the label value produced by the labeller task.
>3 - I use this value plus the NAnt script to actually set the label. 
>
>Since NAnt will exit the script on fail, its perfectly valid to have the 
>following kind of target as your top-level CCNet target

Thanks, its good to know that the label is available to NAnt, but unless I 
am missing something, that doesn't help with the problem at hand. In 
particular it leaves two questions unanswered:

1) What prevents the sc labelling from being called during the CCNET 
post-build step? 

In the Project class, the PostBuild() method calls the LabelBuild() 
method. This in turn calls sc.LabelSourceControl() passing the label, and 
a datetime stamp. VSS.LabelSourceControl() creates the SS label command 
line I described in my first email, whose -Vd flag's behavior is the root 
cause of that problem.

2) How does having NAnt do the labelling call, solve the basic problem 
with VSS labelling? 

(To recap the problem: when doing CI we want to label the repository image 
at a specific time (ideally a moment in time after the last change 
included in the current build file-set, and before any newer changes are 
made), but providing that time to VSS labelling causes VSS to label the 
*existing version* at that time (instead of creating a new version), so 
that unless the Project folder itself (not one of its children) happened 
to be modified in this modification set, CCNET will not create a new 
label, but overwrite the older label with the new name (keeping the same 
old time and other information. See my first email in this thread for 
details)

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
"Is onomatopoeia onomatopoetic? No, its Greek."
http://www.twelve71.com/caputo/

I haven't read all the commentary within this thread, but here's my take 
on labelling and CCNet.

1 - I don't think of the 'labeller' within CCNet as something which 
actually applies a label, more of a 'build number creator'. As such, I 
would only use the default one.
2 - The CCNet NAnt builder passes a property into the NAnt script called 
'label-to-apply' - this is the label value produced by the labeller task.
3 - I use this value plus the NAnt script to actually set the label. 
Since NAnt will exit the script on fail, its perfectly valid to have the 
following kind of target as your top-level CCNet target

<target name="ContinuousIntegration" depends="BuildAndTest, Label, 
PublishArtifacts" />

<target name="Label">
    <ifnot propertyexists="label-to-apply">
       <fail message="Label property not set - cannot perform labelling" />
    </ifnot>
    <property fulllabel="MyProject-CI-${label-to-apply}" />
    <!-- Do my actual label here using a NAnt task or exec, with the 
above label name -->
</target>

Mike

William E Caputo wrote:

>Hi All,
>
>VSS Labelling has an issue, limitation, breakage, whatever you want to 
>call it, that makes labelling almost useless. This is not a bug in CC.NET, 
>but rather a limitation in how VSS does labelling.
>

i'm sure you've already considered this, but why not just get the VSS sc to
label the build after detecting modifications, and not worry about applying
labels from your build at all (this is similar to what we do in the CVS
SourceControl).
ok, so you lose information about whether the build at that label was
successful or not, but you could always cross-reference the build label
against the ccnet web page.
maybe i'm missing something obvious here.
o.


---
R. Owen Rogers
ThoughtWorks Ltd

ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           William E Caputo            |
|         |           <WEC...@th...> |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           17/10/2003 01:29            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       ccn...@li...                                                                                                |
  |       cc:       Josh MacKenzie <JMa...@th...>                                                                                     |
  |       Subject:  [Ccnet-devel] VSS labelling is broken                                                                                            |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Hi All,

VSS Labelling has an issue, limitation, breakage, whatever you want to
call it, that makes labelling almost useless. This is not a bug in CC.NET,
but rather a limitation in how VSS does labelling.

First the symptom:

We noticed that not all of our builds were being labelled. Specifically,
when we checked to roll-back a recent build, we found that there were some
labels, but there was no entry for the most recent good build (nor many
others). The labels that did exist were correctly striped down the entire
project tree.

Details:

I've been poking around in this a good bit today, and it turns out that
the entries listed were only for when the project (i.e. folder) in VSS
changed (and not any of its children). Generally this happens only when
files are added or removed from the project folder (i.e. the folder
pointed at by the CC.NET modset, and the nant vssget). So the few labels
we have were when people added or removed files from that directory.

Why this happens (warning, kinda long, but there are some nifty tables):

Digging further I've isolated why this is happening. The CCNET-issued VSS
command line looks like this:
SS label (projectname) -L(a number that will be the label) -Vd(a date for
when to label) -Y(username, password) ...

In CVS (and other tools) specifying a date will create a label at that
date. In VSS, specifying a date using the -Yd flag puts a label on *the
version* at that date -- it doesn't create a new version. Since the
project folder hasn't changed since the build's start time (which is what
is passed from CC.NET) the version that is there gets labelled -- but
since this was already labelled (say the last time a file was added to the
project folder), that label is *overwritten*. The entry remains the same
(same date, same version, etc.) but the label itself is changed. So for
example, given the following simple tree:

Project
    file1
    file2
    SUBPROJECT
        ...

Say I add file1 at 10/16/03;5:05p, and the build succeeds. The project is
then given a label (e.g. BUILD1), so if we look at the project's history
(filtered only on labels) we will see something like:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD1    2           file1    Added      10/16/03;5:05p    wcaputo

Later, file1 is modified by jcool. CCNET issues a new label on success
(e.g. BUILD2 at 5:07p). Instead of two labels like this (as we expect, and
desire):

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD1    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD2    3           file1    Modified   10/16/03;5:07p    jcool


It looks like this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo

(ugh!) Note that nothing changes but the label itself.

If someone comes along (say cbrown) and deletes file2 at 5:09 our new
label set looks like this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD3    3           file2    Deleted    10/16/03;5:09p    cbrown

Fifteen more successful builds occur (e.g. changes to file1 or to
SUBPROJECT, or one of its files) and we have this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD18   3           file2    Deleted    10/16/03;5:09p    cbrown

Again only the label changed, and now it appears that label entries are
missing (when in fact they have just been overwriting).

Possible workarounds:

I see three possibilities (apart from not labelling at all).

Option A: Leaving the -Vd flag out:

This will create a new label (this syntax actually creates a new version)
each time the command is called. The problem is that the time stamp will
be when the call is made and not when the build started, leaving us with a
gap where bad files can be included in the label, thus defeating the whole
purpose of the label.

Option B: Marking the mod check with a new version:

This is a hack, but I think it can be done. If we issued a label command
right before the modifications were checked (e.g. CCNETCHECK) then used
that time for the label call later, it would overwrite the CCNETCHECK
label with the successful build label.

Option C: Marking the get with a new version label:

This is a variation on the last one. It in turn, has two variants. 1)
Modify the NAnt VSSGET task so that *it* marks the repository (e.g.
NANTGET) or 2) Have CCNET issue a marking label right before calling its
builder (e.g. CCNETBUILD).

Evaluation:

Option A is easy, but I think has too many problems

Option B is easier than C, but means there will be a label for each check.
That's a lot of labels.

Option C1 I don't like because a) its only valid if nant is the builder b)
it means getting the patch accepted to nant c) how do you get the
timestamp back to CCNET?

Option C2 is hardest, because it means changing the workflow outside of
the sourceControl, but it has the advantage of marking every build, and
making it easy to tell by the labels which are successful, and which are
not. It has the added advantage that the timestamp will be very close to
the actual get, but the offsetting disadvantage that the ccnet reported
modset might not match the label exactly (whereas now we have a
get/reporting gap BTW).

Whew! OK, sorry for the length, but it seems like a big problem, its very
confusing, and I wanted to find out if a) I was correct in this analysis
b) what (if anything) others have done about it c) what (if anything) the
ccnet team thinks is the best way to solve it (either one of the listed
options, or some other idea).

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
"Is onomatopoeia onomatopoetic? No, its Greek."
http://www.twelve71.com/caputo/






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

Owen:
>ok, so you lose information about whether the build at that label was 
successful or not, 
>but you could always cross-reference the build label against the ccnet 
web page.
>maybe i'm missing something obvious here.

No, I don't think you missed anything --  I did. Your suggestion is "label 
after check, if mods detected" (let's call this option D). Whereas I 
suggested (in Option B) "label before check" and in option C1 and C2 
"label before get". The thing I missed is that there is a practical 
difference between "after check" and "before get" in terms of scope of 
change.

Option D is a more localized change than either B or C,  and should have 
about the same result as C2. Particularly, issuing a label upon success 
will have the same effect of overwriting the label written earlier. In 
addition, they both share the reduction of the check/get race condition 
that currently exists.

These are the two main reasons I liked C (even though C1 sucks because its 
a NAnt change, it has the same effect). But because it means only 
modifying the VSS sc, Option D should be easier than either version of C.

Thanks Owen, I think I will give this a try.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
"Is onomatopoeia onomatopoetic? No, its Greek."
http://www.twelve71.com/caputo/

Thanks Owen, that definitely helps -- I should have no problem getting it=20
done.

Incidentally, the *reason* I want a prefix labeller is because it is=20
recommended that numeric labels be avoided with VSS. Again because of the=20
command line's -V option:


Avoid Numerical Labels
When used in combination with -vL, labels that start with a number are not =
processed correctly. For=20
example,
ss history $/Test -vL4.0.1~2.0.3
should return history for versions of $/Test between labeled version=20
"2.0.3" and "4.0.1."  In actuality, this command returns history for all=20
versions of the $/Test project, including labeled version "1.0.0", which=20
lies outside the specified range.

(for the curious, I got this from:=20
http://blogs.gotdotnet.com/korbyp/categoryview.aspx/VSS%20Tips%20and%20Tric=
ks)

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
"Is onomatopoeia onomatopoetic? No, its Greek."
http://www.twelve71.com/caputo/








Owen Rogers
10/18/2003 07:32 AM


        To:     William E Caputo <WEC...@th...>@THOUGHTWORKS=
=5FCOM
        cc:     ccn...@li...
        Subject:        Re: [Ccnet-devel] Adding a new labeller

hi bill,

re: 1)
you're right -- the Labeller property in Project needs to be marked up=20
with a ReflectorProperty attribute in order to be loaded in from=20
configuration.  bit of an oversight on our part for missing it.  the=20
InstanceTypeKey property on the attribute is used to specify which=20
attribute in the specified element will contain the ReflectorType name to=20
load.
here's the code:

public class Project
{
        [ReflectorProperty("labeller", InstanceTypeKey=3D"type",=20
Required=3Dfalse)]
        public ILabeller Labeller;
}

here's the xml:
<cruisecontrol>
        <project name=3D"myProject">
                <labeller type=3D"myLabeller" />
        </project>
</cruisecontrol>

this code will populate the Labeller field with an instance of the class=20
marked up with the ReflectorType attribute: [ReflectorType("myLabeller")]. =

 note that this type must implement the ILabeller interface.

re: 2)
to pass the prefix to your labeller class, simply add a sub-element or=20
attribute to the labeller element to specify this prefix.  for example:

<labeller type=3D"myLabeller" >
        <prefix>BUILD: </prefix>
</labeller>

now, your Labeller class would need to have it prefix property/field=20
marked up appropriately with a ReflectorProperty attribute.

for example:

[ReflectorType("myLabeller")]
public class BillsLabeller : ILabeller
{
        [ReflectorProperty("prefix")]
        public string Prefix;

        public string Generate(IntegrationResult result)
        {
                return Prefix + result.Label;
        }

        public void Run(IntegrationResult result)
        {
                ...
        }
}

hope this helps,
o.

---
R. Owen Rogers
ThoughtWorks Ltd

ThoughtWorks - Deliver with passion!




William E Caputo <WEC...@th...>
Sent by: ccn...@li...
16/10/2003 20:46
=20
        To:     ccn...@li...
        cc:=20
        Subject:        [Ccnet-devel] Adding a new labeller






Hi All,

I want to write a new labeller, but I want to understand a little better
how some things work first:

1) Configuring the labeller
The Project class currently hardcodes a DefaultLabeller.

Many of the other Project properties are set in the config file using an
attribute that seems to define a type e.g.:
[ReflectorProperty("build", InstanceTypeKey=3D"type")]

How does that work? For example, if I wanted to add a similar attribute=20
for
the Labeller property so that my new labeller can be specified in the
config file (and the default labeller created if its not set) what would I
have to do?

2) Passing parameters to the labeller.

The labeller I want to build is a Prefix labeller. Given a prefix (e.g.
BUILD), the labels will be produced as BUILDn where n is the current
increment. The labeller will increment the numeric part, and then concat
the two together. I would like to be able to specify the label prefix in
the config file, how would that change the answer to number 1)?

Thanks.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
http://www.twelve71.com/caputo/






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

yup, StreamWriter is the culprit.  here's the decompiled code courtesy of
Reflector:

                                                                           
 public StreamWriter(string path,                                          
 bool append, Encoding encoding, int                                       
 bufferSize)                                                               
 {                                                                         
                                                                           
                                                                           
                                                                           
                                                                           
   Stream stream1;                                                         
   base..ctor();                                                           
   if ((path == null) || (encoding ==                                      
   null))                                                                  
   {                                                                       
                                                                           
                                                                           
                                                                           
                                                                           
      throw new ArgumentNullException                                      
      (((path == null) ? "path" :                                          
      "encoding"));                                                        
                                                                           
   }                                                                       
   if (bufferSize <= 0)                                                    
   {                                                                       
                                                                           
                                                                           
                                                                           
                                                                           
      throw new                                                            
      ArgumentOutOfRangeException(                                         
      Environment.GetResourceString                                        
      ("ArgumentOutOfRange_NeedPosNum                                      
      "));                                                                 
                                                                           
   }                                                                       
   stream1 = StreamWriter.CreateFile                                       
   (path, append);                                                         
   this.Init(stream1, encoding,                                            
   bufferSize);                                                            
                                                                           
 }                                                                         
                                                                           



o.


---
R. Owen Rogers
ThoughtWorks Ltd

ThoughtWorks - Deliver with passion!


|---------+---------------------------->
|         |           Drew Noakes      |
|         |                            |
|         |           18/10/2003 14:35 |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:      Owen Rogers <OR...@th...>@THOUGHTWORKS_COM                                                                           |
  |       cc:      "Ccnet-Devel (E-mail)" <ccn...@li...>, ccn...@li...                               |
  |       Subject: Re: [Ccnet-devel] Corrupted state file(Document link: Owen Rogers)                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|



I checked the Xml state file before deleting it... it was empty!  My guess
is that we stopped (CTRL+C) the server while it was finishing up a build.
Maybe we should find out if there's a way to protect against this scenario
in addition to handling badly formed Xml.

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...




|---------+--------------------------------------->
|         |           Owen Rogers                 |
|         |           <OR...@th...>  |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           18/10/2003 07:16            |
|         |                                       |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       "Michael C Two <MCTwo"                                                                                                           |
  |       cc:       "Ccnet-Devel (E-mail)" <ccn...@li...>                                                                       |
  |       Subject:  Re: [Ccnet-devel] Corrupted state file                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|








now that the IntegrationResult.Output property is no longer being
serialised (it's now marked up with [XmlIgnore], it should not corrupt the
state file any more if it contains bad xml.
drew: is this where the bad xml is coming from (he asks hoping that drew
hasn't yet deleted the state file).
cheers,
o.

---
R. Owen Rogers
ThoughtWorks Ltd


ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           Michael C Two               |
|         |           <MC...@th...>    |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           17/10/2003 14:18            |
|---------+--------------------------------------->

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       no...@bp...
|
  |       cc:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       Subject:  Re: [Ccnet-devel] Corrupted state file
|

>--------------------------------------------------------------------------------------------------------------------------------------------------|









When this happens I usually just delete the state file, run the build again
with any labeling or checkin tasks disabled., usually just run the compile
That produces a new state file but the build number is going to be 1 (which
is why I don't let it check in or anything). I then edit the state file by
hand to get the build number sequencing right and then run a full build.

Most of the time this happens to me it is due to a blow up in nunit that
causes nant to really fail and produce bad xml.

ThoughtWorks, where being meta-cognitive is something worth thinking about.


|---------+--------------------------------------->
|         |           "Noakes, Drew               |
|         |           (Thoughtworks)"             |
|         |           <no...@bp...>             |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           10/17/2003 04:38 AM         |
|         |                                       |
|---------+--------------------------------------->

>------------------------------------------------------------------------------------------------------------------------------|


  |
|
  |       To:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       cc:
|
  |       Subject:  [Ccnet-devel] Corrupted state file
|

>------------------------------------------------------------------------------------------------------------------------------|






Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project threw
an exception while integrating System.InvalidOperationException: There is
an error in XML document (0, 0). ---> System.Xml.XmlException: The root
element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read6_IntegrationResult()



   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult&
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition buildCondition)
in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and write a
fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  Similarly,
if anyone's doing major work on IntegrationStateManager, please let me
know.

Drew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

actually, i've observed this problem as well -- killing ccnet at just the
wrong time.
looking at the IntegrationStateManager, it instantiates a StreamWriter with
the filename of the state file before it begins serialisation.  does this
immediately clear the file?  if so, this could be the culprit.
o.


---
R. Owen Rogers
ThoughtWorks Ltd


ThoughtWorks - Deliver with passion!


|---------+---------------------------->
|         |           Drew Noakes      |
|         |                            |
|         |           18/10/2003 14:35 |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:      Owen Rogers <OR...@th...>@THOUGHTWORKS_COM                                                                           |
  |       cc:      "Ccnet-Devel (E-mail)" <ccn...@li...>, ccn...@li...                               |
  |       Subject: Re: [Ccnet-devel] Corrupted state file(Document link: Owen Rogers)                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|



I checked the Xml state file before deleting it... it was empty!  My guess
is that we stopped (CTRL+C) the server while it was finishing up a build.
Maybe we should find out if there's a way to protect against this scenario
in addition to handling badly formed Xml.

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...




|---------+--------------------------------------->
|         |           Owen Rogers                 |
|         |           <OR...@th...>  |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           18/10/2003 07:16            |
|         |                                       |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       "Michael C Two <MCTwo"                                                                                                           |
  |       cc:       "Ccnet-Devel (E-mail)" <ccn...@li...>                                                                       |
  |       Subject:  Re: [Ccnet-devel] Corrupted state file                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|








now that the IntegrationResult.Output property is no longer being
serialised (it's now marked up with [XmlIgnore], it should not corrupt the
state file any more if it contains bad xml.
drew: is this where the bad xml is coming from (he asks hoping that drew
hasn't yet deleted the state file).
cheers,
o.

---
R. Owen Rogers
ThoughtWorks Ltd


ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           Michael C Two               |
|         |           <MC...@th...>    |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           17/10/2003 14:18            |
|---------+--------------------------------------->

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       no...@bp...
|
  |       cc:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       Subject:  Re: [Ccnet-devel] Corrupted state file
|

>--------------------------------------------------------------------------------------------------------------------------------------------------|









When this happens I usually just delete the state file, run the build again
with any labeling or checkin tasks disabled., usually just run the compile
That produces a new state file but the build number is going to be 1 (which
is why I don't let it check in or anything). I then edit the state file by
hand to get the build number sequencing right and then run a full build.

Most of the time this happens to me it is due to a blow up in nunit that
causes nant to really fail and produce bad xml.

ThoughtWorks, where being meta-cognitive is something worth thinking about.


|---------+--------------------------------------->
|         |           "Noakes, Drew               |
|         |           (Thoughtworks)"             |
|         |           <no...@bp...>             |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           10/17/2003 04:38 AM         |
|         |                                       |
|---------+--------------------------------------->

>------------------------------------------------------------------------------------------------------------------------------|


  |
|
  |       To:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       cc:
|
  |       Subject:  [Ccnet-devel] Corrupted state file
|

>------------------------------------------------------------------------------------------------------------------------------|






Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project threw
an exception while integrating System.InvalidOperationException: There is
an error in XML document (0, 0). ---> System.Xml.XmlException: The root
element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read6_IntegrationResult()



   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult&
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition buildCondition)
in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and write a
fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  Similarly,
if anyone's doing major work on IntegrationStateManager, please let me
know.

Drew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

I checked the Xml state file before deleting it... it was empty!  My guess 
is that we stopped (CTRL+C) the server while it was finishing up a build. 
Maybe we should find out if there's a way to protect against this scenario 
in addition to handling badly formed Xml.

Drew Noakes

ThoughtWorks, Inc. UK
dr...@th...






Owen Rogers <OR...@th...>
Sent by: ccn...@li...
18/10/2003 07:16

 
        To:     "Michael C Two <MCTwo"
        cc:     "Ccnet-Devel (E-mail)" <ccn...@li...>
        Subject:        Re: [Ccnet-devel] Corrupted state file






now that the IntegrationResult.Output property is no longer being
serialised (it's now marked up with [XmlIgnore], it should not corrupt the
state file any more if it contains bad xml.
drew: is this where the bad xml is coming from (he asks hoping that drew
hasn't yet deleted the state file).
cheers,
o.

---
R. Owen Rogers
ThoughtWorks Ltd


ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           Michael C Two               |
|         |           <MC...@th...>    |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           17/10/2003 14:18            |
|---------+--------------------------------------->
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |     |
  |       To:       no...@bp...                                   |
  |       cc:       "Ccnet-Devel (E-mail)" 
<ccn...@li...>                                |
  |       Subject:  Re: [Ccnet-devel] Corrupted state file          |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|








When this happens I usually just delete the state file, run the build 
again
with any labeling or checkin tasks disabled., usually just run the compile
That produces a new state file but the build number is going to be 1 
(which
is why I don't let it check in or anything). I then edit the state file by
hand to get the build number sequencing right and then run a full build.

Most of the time this happens to me it is due to a blow up in nunit that
causes nant to really fail and produce bad xml.

ThoughtWorks, where being meta-cognitive is something worth thinking 
about.


|---------+--------------------------------------->
|         |           "Noakes, Drew               |
|         |           (Thoughtworks)"             |
|         |           <no...@bp...>             |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           10/17/2003 04:38 AM         |
|         |                                       |
|---------+--------------------------------------->

>------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       cc:
|
  |       Subject:  [Ccnet-devel] Corrupted state file
|

>------------------------------------------------------------------------------------------------------------------------------|





Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project 
threw
an exception while integrating System.InvalidOperationException: There is
an error in XML document (0, 0). ---> System.Xml.XmlException: The root
element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read6_IntegrationResult()


   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult&
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition buildCondition)
in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and write 
a
fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  Similarly,
if anyone's doing major work on IntegrationStateManager, please let me
know.

Drew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel




-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

hi bill,

re: 1)
you're right -- the Labeller property in Project needs to be marked up with
a ReflectorProperty attribute in order to be loaded in from configuration.
bit of an oversight on our part for missing it.  the InstanceTypeKey
property on the attribute is used to specify which attribute in the
specified element will contain the ReflectorType name to load.
here's the code:

public class Project
{
      [ReflectorProperty("labeller", InstanceTypeKey="type",
Required=false)]
      public ILabeller Labeller;
}

here's the xml:
<cruisecontrol>
      <project name="myProject">
            <labeller type="myLabeller" />
      </project>
</cruisecontrol>

this code will populate the Labeller field with an instance of the class
marked up with the ReflectorType attribute: [ReflectorType("myLabeller")].
note that this type must implement the ILabeller interface.

re: 2)
to pass the prefix to your labeller class, simply add a sub-element or
attribute to the labeller element to specify this prefix.  for example:

<labeller type="myLabeller" >
      <prefix>BUILD: </prefix>
</labeller>

now, your Labeller class would need to have it prefix property/field marked
up appropriately with a ReflectorProperty attribute.

for example:

[ReflectorType("myLabeller")]
public class BillsLabeller : ILabeller
{
      [ReflectorProperty("prefix")]
      public string Prefix;

      public string Generate(IntegrationResult result)
      {
            return Prefix + result.Label;
      }

      public void Run(IntegrationResult result)
      {
            ...
      }
}

hope this helps,
o.

---
R. Owen Rogers
ThoughtWorks Ltd

ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           William E Caputo            |
|         |           <WEC...@th...> |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           16/10/2003 20:46            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       ccn...@li...                                                                                                |
  |       cc:                                                                                                                                        |
  |       Subject:  [Ccnet-devel] Adding a new labeller                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|








Hi All,

I want to write a new labeller, but I want to understand a little better
how some things work first:

1) Configuring the labeller
The Project class currently hardcodes a DefaultLabeller.

Many of the other Project properties are set in the config file using an
attribute that seems to define a type e.g.:
[ReflectorProperty("build", InstanceTypeKey="type")]

How does that work? For example, if I wanted to add a similar attribute for
the Labeller property so that my new labeller can be specified in the
config file (and the default labeller created if its not set) what would I
have to do?

2) Passing parameters to the labeller.

The labeller I want to build is a Prefix labeller. Given a prefix (e.g.
BUILD), the labels will be produced as BUILDn where n is the current
increment. The labeller will increment the numeric part, and then concat
the two together. I would like to be able to specify the label prefix in
the config file, how would that change the answer to number 1)?

Thanks.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
http://www.twelve71.com/caputo/






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

now that the IntegrationResult.Output property is no longer being
serialised (it's now marked up with [XmlIgnore], it should not corrupt the
state file any more if it contains bad xml.
drew: is this where the bad xml is coming from (he asks hoping that drew
hasn't yet deleted the state file).
cheers,
o.

---
R. Owen Rogers
ThoughtWorks Ltd


ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           Michael C Two               |
|         |           <MC...@th...>    |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           17/10/2003 14:18            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       no...@bp...                                                                                                                    |
  |       cc:       "Ccnet-Devel (E-mail)" <ccn...@li...>                                                                       |
  |       Subject:  Re: [Ccnet-devel] Corrupted state file                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|








When this happens I usually just delete the state file, run the build again
with any labeling or checkin tasks disabled., usually just run the compile
That produces a new state file but the build number is going to be 1 (which
is why I don't let it check in or anything). I then edit the state file by
hand to get the build number sequencing right and then run a full build.

Most of the time this happens to me it is due to a blow up in nunit that
causes nant to really fail and produce bad xml.

ThoughtWorks, where being meta-cognitive is something worth thinking about.


|---------+--------------------------------------->
|         |           "Noakes, Drew               |
|         |           (Thoughtworks)"             |
|         |           <no...@bp...>             |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           10/17/2003 04:38 AM         |
|         |                                       |
|---------+--------------------------------------->

>------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       "Ccnet-Devel (E-mail)"
<ccn...@li...>
|
  |       cc:
|
  |       Subject:  [Ccnet-devel] Corrupted state file
|

>------------------------------------------------------------------------------------------------------------------------------|





Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project threw
an exception while integrating System.InvalidOperationException: There is
an error in XML document (0, 0). ---> System.Xml.XmlException: The root
element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read6_IntegrationResult()


   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult&
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition buildCondition)
in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and write a
fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  Similarly,
if anyone's doing major work on IntegrationStateManager, please let me
know.

Drew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

When this happens I usually just delete the state file, run the build again
with any labeling or checkin tasks disabled., usually just run the compile
That produces a new state file but the build number is going to be 1 (which
is why I don't let it check in or anything). I then edit the state file by
hand to get the build number sequencing right and then run a full build.

Most of the time this happens to me it is due to a blow up in nunit that
causes nant to really fail and produce bad xml.

ThoughtWorks, where being meta-cognitive is something worth thinking about.


|---------+--------------------------------------->
|         |           "Noakes, Drew               |
|         |           (Thoughtworks)"             |
|         |           <no...@bp...>             |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           10/17/2003 04:38 AM         |
|         |                                       |
|---------+--------------------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       "Ccnet-Devel (E-mail)" <ccn...@li...>                                                   |
  |       cc:                                                                                                                    |
  |       Subject:  [Ccnet-devel] Corrupted state file                                                                           |
  >------------------------------------------------------------------------------------------------------------------------------|




Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project threw
an exception while integrating System.InvalidOperationException: There is
an error in XML document (0, 0). ---> System.Xml.XmlException: The root
element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read6_IntegrationResult()

   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult&
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition buildCondition)
in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and write a
fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  Similarly,
if anyone's doing major work on IntegrationStateManager, please let me
know.

Drew



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

Howdy.

Somehow, our project has a corrupt ccnet.state file, and the Xml =
deserialisation is barfing.

Here's a stacktrace to stare at for a while on a Friday:

[project: CAT] Project threw an exception while integrating.: Project =
threw an exception while integrating System.InvalidOperationException: =
There is an error in XML document (0, 0). ---> System.Xml.XmlException: =
The root element is missing.
   at System.Xml.XmlTextReader.Read()
   at System.Xml.XmlReader.MoveToContent()
   at =
Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Rea=
d6_IntegrationResult()
   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader =
xmlReader, String encodingStyle)
   at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader =
textReader)
   at tw.ccnet.core.state.IntegrationStateManager.LoadState() in =
C:\CCNetDev\ccnet\project\core\state\IntegrationStateManager.cs:line 56
   at tw.ccnet.core.Project.LoadLastIntegration() in =
c:\ccnetdev\ccnet\project\core\project.cs:line 297
   at tw.ccnet.core.Project.get_LastIntegrationResult() in =
c:\ccnetdev\ccnet\project\core\project.cs:line 163
   at =
tw.ccnet.core.Project.CreateNewIntegrationResult(IntegrationResult& =
results) in c:\ccnetdev\ccnet\project\core\project.cs:line 226
   at tw.ccnet.core.Project.RunIntegration(BuildCondition =
buildCondition) in c:\ccnetdev\ccnet\project\core\project.cs:line 190
   at tw.ccnet.core.ProjectIntegrator.Run() in =
C:\CCNetDev\ccnet\project\core\ProjectIntegrator.cs:line 88

Anyway, I'm going to try (depending upon how long it will take) and =
write a fix that renames the corrupted file, and starts a-fresh.

If anyone has thoughts to inject into this work, please share.  =
Similarly, if anyone's doing major work on IntegrationStateManager, =
please let me know.

Drew

Hi All,

VSS Labelling has an issue, limitation, breakage, whatever you want to 
call it, that makes labelling almost useless. This is not a bug in CC.NET, 
but rather a limitation in how VSS does labelling.

First the symptom:

We noticed that not all of our builds were being labelled. Specifically, 
when we checked to roll-back a recent build, we found that there were some 
labels, but there was no entry for the most recent good build (nor many 
others). The labels that did exist were correctly striped down the entire 
project tree.

Details:

I've been poking around in this a good bit today, and it turns out that 
the entries listed were only for when the project (i.e. folder) in VSS 
changed (and not any of its children). Generally this happens only when 
files are added or removed from the project folder (i.e. the folder 
pointed at by the CC.NET modset, and the nant vssget). So the few labels 
we have were when people added or removed files from that directory.

Why this happens (warning, kinda long, but there are some nifty tables):

Digging further I've isolated why this is happening. The CCNET-issued VSS 
command line looks like this:
SS label (projectname) -L(a number that will be the label) -Vd(a date for 
when to label) -Y(username, password) ...

In CVS (and other tools) specifying a date will create a label at that 
date. In VSS, specifying a date using the -Yd flag puts a label on *the 
version* at that date -- it doesn't create a new version. Since the 
project folder hasn't changed since the build's start time (which is what 
is passed from CC.NET) the version that is there gets labelled -- but 
since this was already labelled (say the last time a file was added to the 
project folder), that label is *overwritten*. The entry remains the same 
(same date, same version, etc.) but the label itself is changed. So for 
example, given the following simple tree:

Project
    file1
    file2
    SUBPROJECT
        ...

Say I add file1 at 10/16/03;5:05p, and the build succeeds. The project is 
then given a label (e.g. BUILD1), so if we look at the project's history 
(filtered only on labels) we will see something like:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD1    2           file1    Added      10/16/03;5:05p    wcaputo

Later, file1 is modified by jcool. CCNET issues a new label on success 
(e.g. BUILD2 at 5:07p). Instead of two labels like this (as we expect, and 
desire):

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD1    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD2    3           file1    Modified   10/16/03;5:07p    jcool


It looks like this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo

(ugh!) Note that nothing changes but the label itself.

If someone comes along (say cbrown) and deletes file2 at 5:09 our new 
label set looks like this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD3    3           file2    Deleted    10/16/03;5:09p    cbrown

Fifteen more successful builds occur (e.g. changes to file1 or to 
SUBPROJECT, or one of its files) and we have this:

Label     Version     Item     Action     Date              User
-------------------------------------------------------------------
BUILD2    2           file1    Added      10/16/03;5:05p    wcaputo
BUILD18   3           file2    Deleted    10/16/03;5:09p    cbrown

Again only the label changed, and now it appears that label entries are 
missing (when in fact they have just been overwriting).

Possible workarounds:

I see three possibilities (apart from not labelling at all).

Option A: Leaving the -Vd flag out:

This will create a new label (this syntax actually creates a new version) 
each time the command is called. The problem is that the time stamp will 
be when the call is made and not when the build started, leaving us with a 
gap where bad files can be included in the label, thus defeating the whole 
purpose of the label.

Option B: Marking the mod check with a new version:

This is a hack, but I think it can be done. If we issued a label command 
right before the modifications were checked (e.g. CCNETCHECK) then used 
that time for the label call later, it would overwrite the CCNETCHECK 
label with the successful build label.

Option C: Marking the get with a new version label:

This is a variation on the last one. It in turn, has two variants. 1) 
Modify the NAnt VSSGET task so that *it* marks the repository (e.g. 
NANTGET) or 2) Have CCNET issue a marking label right before calling its 
builder (e.g. CCNETBUILD). 

Evaluation:

Option A is easy, but I think has too many problems

Option B is easier than C, but means there will be a label for each check. 
That's a lot of labels.

Option C1 I don't like because a) its only valid if nant is the builder b) 
it means getting the patch accepted to nant c) how do you get the 
timestamp back to CCNET?

Option C2 is hardest, because it means changing the workflow outside of 
the sourceControl, but it has the advantage of marking every build, and 
making it easy to tell by the labels which are successful, and which are 
not. It has the added advantage that the timestamp will be very close to 
the actual get, but the offsetting disadvantage that the ccnet reported 
modset might not match the label exactly (whereas now we have a 
get/reporting gap BTW).

Whew! OK, sorry for the length, but it seems like a big problem, its very 
confusing, and I wanted to find out if a) I was correct in this analysis 
b) what (if anything) others have done about it c) what (if anything) the 
ccnet team thinks is the best way to solve it (either one of the listed 
options, or some other idea).

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
"Is onomatopoeia onomatopoetic? No, its Greek."
http://www.twelve71.com/caputo/

Hi All,

I want to write a new labeller, but I want to understand a little better
how some things work first:

1) Configuring the labeller
The Project class currently hardcodes a DefaultLabeller.

Many of the other Project properties are set in the config file using an
attribute that seems to define a type e.g.:
[ReflectorProperty("build", InstanceTypeKey="type")]

How does that work? For example, if I wanted to add a similar attribute for
the Labeller property so that my new labeller can be specified in the
config file (and the default labeller created if its not set) what would I
have to do?

2) Passing parameters to the labeller.

The labeller I want to build is a Prefix labeller. Given a prefix (e.g.
BUILD), the labels will be produced as BUILDn where n is the current
increment. The labeller will increment the numeric part, and then concat
the two together. I would like to be able to specify the label prefix in
the config file, how would that change the answer to number 1)?

Thanks.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.
--------
A Plan is a list of things that don't happen
http://www.twelve71.com/caputo/

hi are,
thanks for your offer.  we are always looking for people to help identify
bugs and submit patches to ccnet.  anything you can do to help would be
appreciated.
can you provide us with more information about the DateTime string
conversion problems that you are having?
also, please cc the ccnet development list
(ccn...@li...) with your reply.
cheers,
owen.

On Sun, 05 Oct 2003 11:09:37 -0700, "Are Bj=F8lseth"
<abj...@us...> said:
>=20
> Hi!
>=20
> I'm following the progress of ccnet by building the src and=20
>=20
> testing the build with nighly compiles on a different project=20
>=20
> (NAnt examples ;-) from an cvsnt server.
>=20
> However, I found several problems with DateTime to string=20
>=20
> conversions, when running the NUnit tests.
>=20
> Perhaps, I can make a small contribution by joining the the=20
>=20
> test team?
>=20
>=20
>=20
> Cheers
>=20
> Are Bjolseth
--=20
  Owen Rogers
  www.exortech.com

mike,
i'm basically finished a very simple generic workflow (should be able t=
o
check in the code tomorrow).  the changes were really quite simple to m=
ake.
the basic structure is this: everything currently contained within a
project (builders, sourcecontrols, publishers, labellers) are all treat=
ed
as generic tasks and are executed in the order they are specified in th=
e
ccnet.config file.  the exception to this is the Schedule and the
StateManager (neither of which are tasks).  you can have multiple sourc=
e
controls or you can have none and you can place them in any order withi=
n
the flow.

the xml configuration file actually looks basically the same as it does=

right now; however the builder, sourcecontrol, publisher, labeller elem=
ents
are now encapsulated in a <tasks> tag.  so, you end up with:

<cruisecontrol>=00=A0 <project name=3D"MyProject" type=3D"generic">=00=A0=
=A0=A0 <schedule
type=3D"schedule" timeout=3D"60000"/>=00=A0=A0=A0 <state directory=3D"c=
:\temp" />=00
<modificationDelay>10000</modificationDelay>
    <tasks>
      =A0=A0=A0 <sourcecontrol type=3D"cvs">=00
<executable>c:\putty\cvswithplinkrsh.bat</executable>
      =A0=A0=A0=A0=A0 <workingDirectory>c:\fromcvs\myrepo</workingDirec=
tory>
      =A0=A0=A0=A0=A0 <cvsroot>:ext:mycvsserver:/cvsroot/myrepo</cvsroo=
t>
      =A0=A0=A0 </sourcecontrol>
      =A0=A0=A0 <build type=3D"nant">=00
<executable>c:\fromcvs\myrepo\myproject\tools\nant\nant.exe</executable=
>
      =A0=A0=A0=A0=A0 <baseDirectory>c:\fromcvs\myrepo\myproject</baseD=
irectory>=00
 <buildArgs>-D:cvs.executable=3Dc:\putty\cvswithplinkrsh.bat</buildArgs=
>
      =A0=A0=A0=A0=A0 <buildFile>cruise.build</buildFile>=00=A0=A0=A0=A0=
=A0   <targetList>
      =A0=A0=A0=A0=A0=A0=A0 <target>run</target>=00=A0=A0=A0=A0=A0    <=
/targetList>
      =A0=A0=A0=A0=A0 <buildTimeout>300000</buildTimeout>
      =A0=A0=A0 </build>=00   =A0=A0=A0=A0=A0 <email from=3D"buildmaste=
r...@my..."
mailhost=3D"smtp.mycompany.com" includeDetails=3D"TRUE">=00
<projectUrl>http://buildserver/myproject</projectUrl>
      =A0=A0=A0=A0=A0=A0 <users>
      =A0=A0=A0=A0=A0=A0=A0=A0=A0 <user name=3D"BuildGuru" group=3D"bui=
ldmaster"
address=3D"bui...@my..."/>=00=A0=A0=A0=A0=A0  =A0=A0=A0=A0 <=
user name=3D"JoeDeveloper"
group=3D"developers" address=3D"joe...@th..."/>
      =A0=A0=A0=A0=A0=A0=A0 </users>=00=A0=A0=A0=A0=A0   =A0=A0 <groups=
>=00=A0=A0=A0=A0=A0=A0=A0=A0=A0    <group
name=3D"developers" notification=3D"change"/>
      =A0=A0=A0=A0=A0=A0=A0=A0=A0 <group name=3D"buildmaster" notificat=
ion=3D"always"/>=00
</groups>
      =A0=A0=A0 </email>=00=A0=A0=A0=A0=A0    <xmllogger>
      =A0=A0=A0=A0=A0=A0=A0 <logDir>..\..\website\log</logDir>=00
<mergeFiles>=00
<file>c:\fromcvs\myrepo\myproject\build\tests\*-results.xml</file>
      =A0=A0=A0=A0=A0=A0=A0 </mergeFiles>=00=A0=A0=A0=A0=A0    </xmllog=
ger>
      </tasks>
=A0 </project>
</cruisecontrol>


Note the 'type=3D"generic"' in the <project> tag.  this is specifying t=
he
pluggable project to use.
Note also that the publishers tag has now disappeared.  the publishers =
can
now be scattered in any order throughout the flow.

In addition, the ITask interface now has a ShouldRun method.  each task=
 now
specifies the conditions under which it should run.  for example, a bui=
lder
task only runs if modifications have been found, and a sourcecontrol ta=
sk
only runs if the integration is currently working.  i am intending to m=
ake
these TaskExecutionConditions configurable so the default behaviour can=
 be
overridden as desired.  think of them as a configurable guard class for=
 the
task (with sensible defaults).

cheers,
owen.

---
R. Owen Rogers
ThoughtWorks Ltd

ThoughtWorks - Deliver with passion!


|---------+--------------------------------------->
|         |           Mike Roberts                |
|         |           <mike.roberts@thoughtworks.n|
|         |           et>                         |
|         |           Sent by:                    |
|         |           ccn...@li...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           06/10/2003 18:56            |
|---------+--------------------------------------->
  >--------------------------------------------------------------------=
-----------------------------------------------------------------------=
-------|
  |                                                                    =
                                                                       =
       |
  |       To:       ccn...@li...                  =
                                                                       =
       |
  |       cc:                                                          =
                                                                       =
       |
  |       Subject:  Re: [Ccnet-devel] CruiseControl.NET to do sync (was=
 Strange build page)                                                   =
       |
  >--------------------------------------------------------------------=
-----------------------------------------------------------------------=
-------|




So thinking more about the tasks thing from last week, I think it would=

be even cooler to do:

<cruisecontrol>
 <project name=3D"MyProject">
   <schedule type=3D"schedule" timeout=3D"60000"/>
   <modificationDelay>10000</modificationDelay>
   <modificationChecker type=3D"cvs">
     <executable>c:\putty\cvswithplinkrsh.bat</executable>
     <workingDirectory>c:\fromcvs\myrepo\myproject</workingDirectory>
   </modificationChecker>
   <task type=3D"SimpleWorkflow">
     <task type=3D"nant" name=3D"prebuild">
         .
         for bootstrapping ?
         .
     </task>
     <task type=3D"nant" name=3D"build">
         .
     </task>
     <task type=3D"email">
         .
     </task>
     <task type=3D"xmllogger">
         .
     </task>
   </task>
</project>
</cruisecontrol>

The task would be instantiated for each run. Owen (I presume it was him=

:) ) has already checked in a relevant interface.

Simple workflow by default would run each sub-task serially. If one tas=
k
failed, the next ones would still run.

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
=