ccnet-devel Mailing List for CruiseControl.NET

Would it be possible to support build progress on the Dashboard?

This could possibly be achieved by the cruisecontrol server detecting 
strings that are output in a specific syntax from the build process. 

i.e. In Nant you could <echo message="[PROGRESS] 10%" />

The CruiseControl dashboard could convert the last of these recieved into 
a percentage bar, much the same as the NUnit output bar graphs.

This would be very useful for big monolithic builds.

Cheers,
Chris.

-- 
Christopher Guest
Senior Software Engineer, Sophos

Tel: 01235 559933
Web: www.sophos.com
Protecting business against viruses, spyware, spam and policy abuse

Greetings all,

While the current file source control / filtering operation is certainly
functional, it is also slow in situations where a large number of
folders are being examined (especially when many of those folders are
excluded by the filter).

Obviously it won't happen before the 1.0 release, but it would be nice
if the file source control could also include some type of filtering to
prevent burrowing N levels deep in a directory structure when it'll be
filtered at the first level.

Any thoughts about this? I couldn't see a Jira for it, should one be
submitted?

Regards,
Richard

i'm fine with it.  +1.
o.

On 22/08/05, Mike Roberts <mik...@gm...> wrote:
> Hi all,
>=20
> Probably only of interest to Graham and Owen this, but I'd like to
> discuss what we do with the codebase w.r.t. branching post 1.0 .
>=20
> In short, I'd like to create a 1.0 Release Branch that will live for
> the lifetime of the 1.0.x releases. Why? Because I think we have 2
> conflicting streams of work for the coming months:
>=20
> 1 - Maintain a set of 1.0.x releases that offer bug fixes / code
> enhancements yet also maintain a stable API and configuration format.
> 2 - Push forward with new behaviour (artifact management, new
> threading model, etc)
>=20
> I don't see any way of us doing option 2 on the same code line as
> option 1 without risking the stability of the 1.0.x codebase. I know
> this isn't the normal thing I'd recommend on a project, but I think
> the inconsistency of our velocity due to us only being part-time
> coders on the project forces us down this route.
>=20
> If we agree on doing this, I suggest the following w.r.t. to ongoing work=
:
> - for each change to CCNet we should consider whether it can be
> applied to the 1.0.x branch or not. If it can, the primary change
> should be made to the branch and then merged onto the (relatively
> unstable) trunk ASAP afterwards. I will be writing instructions on how
> this can be done.
> - if it can't be applied to the 1.0.x branch it should be applied to
> the trunk ONLY.
>=20
> Of course, both the branch and trunk would have their own CCNetLive proje=
cts.
>=20
> At some point, we will decide that the trunk should be used to produce
> a published release. At that time we will stabilise the trunk and
> retire the 1.0.x release branch.
>=20
> Any thoughts?
>=20
> Cheers,
>=20
> Mike
>=20
> --
> mike roberts | http://mikeroberts.thoughtworks.net/ |
> http://www.thoughtworks.com/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Mike,

I agree with your "branch as a last resort" strategy -- apparently there's
some new fangled approach that can repeatably deliver quality software
without the complexity of traditional branch-heavy SCM. I think it's
called continuous integration or something like that.

I also agree that ccnet doesn't have sufficient (any?)
integration/acceptance tests in order to make the kind of changes we want
to make with test protection -- and I also don't have the time to help
write them.

So creating a stable "1.0.x" branch seems the least of all evils. 

> I don't see any way of us doing option 2 on the same code line as
> option 1 without risking the stability of the 1.0.x codebase. I know
> this isn't the normal thing I'd recommend on a project, but I think
> the inconsistency of our velocity due to us only being part-time
> coders on the project forces us down this route.

Agreed.  What we do need is a clear naming policy for the stable and
unstable code lines (and build servers and releases etc).  Do we just keep
the 1.0 branch at 1.0.x.buildNumber and move the trunk to
1.1.x.buildNumber?  

The current approach taken is to update the major.minor just before
release, so the first build that's called 1.0 is the one that is released.
We'll need to change that so that the trunk becomes 1.1 immediately after
creating the 1.0 branch, effectively making it the *last* build of that
version number being the one that is released.

> If we agree on doing this, I suggest the following w.r.t. to ongoing
work:
> - for each change to CCNet we should consider whether it can be
> applied to the 1.0.x branch or not. If it can, the primary change
> should be made to the branch and then merged onto the (relatively
> unstable) trunk ASAP afterwards. I will be writing instructions on how
> this can be done.
> - if it can't be applied to the 1.0.x branch it should be applied to
> the trunk ONLY.

Hmm. So what's the rule of thumb?  Fixes on 1.0, enhancements on 1.1?  Or
just those enhancements that we judge to have "significant" impact on the
codebase?   Or those that we view as high risk?   So, for example, some of
the enhancements suggested to cctray could probably reasonably be done on
1.0 since the risk is minimal. Agreed?

We also need to be clear in JIRA as to where things have been implemented.
Do this just mean having a "1.0.1" version and a "1.1" version that we can
assign completed items to? 

Cheers
g

On 8/22/05, Kim Gr=E4sman <ki...@mv...> wrote:
> Hi Mike,
>=20
> I assume you mean it's unusual because there's active development in
> both trunk and release branch, and not just maintenance work in the
> release branch?

I don't tend to like branching at all. On a 'real' project I like to
stick to a more iterative model, releasing on every iteration, or at
least being able to release every iteration. This requires a good
suite of automated acceptance tests and automated upgrade procedures.
We could do that on CCNet, but I (at least) don't have the time to
work on either of these 2 areas.

Mike

Hi Mike,

> I suggest the following w.r.t. to ongoing work: 
 > - for each change to CCNet we should consider whether it can be
> applied to the 1.0.x branch or not. If it can, the primary change 
> should be made to the branch and then merged onto the (relatively 
> unstable) trunk ASAP afterwards. I will be writing instructions on 
> how this can be done. 
 > - if it can't be applied to the 1.0.x branch it
> should be applied to the trunk ONLY.
> 
> Of course, both the branch and trunk would have their own CCNetLive 
> projects.

FWIW, I think this sounds perfectly reasonable.

I assume you mean it's unusual because there's active development in 
both trunk and release branch, and not just maintenance work in the 
release branch?

- Kim

Hi all,

Probably only of interest to Graham and Owen this, but I'd like to
discuss what we do with the codebase w.r.t. branching post 1.0 .

In short, I'd like to create a 1.0 Release Branch that will live for
the lifetime of the 1.0.x releases. Why? Because I think we have 2
conflicting streams of work for the coming months:

1 - Maintain a set of 1.0.x releases that offer bug fixes / code
enhancements yet also maintain a stable API and configuration format.
2 - Push forward with new behaviour (artifact management, new
threading model, etc)

I don't see any way of us doing option 2 on the same code line as
option 1 without risking the stability of the 1.0.x codebase. I know
this isn't the normal thing I'd recommend on a project, but I think
the inconsistency of our velocity due to us only being part-time
coders on the project forces us down this route.

If we agree on doing this, I suggest the following w.r.t. to ongoing work:
- for each change to CCNet we should consider whether it can be
applied to the 1.0.x branch or not. If it can, the primary change
should be made to the branch and then merged onto the (relatively
unstable) trunk ASAP afterwards. I will be writing instructions on how
this can be done.
- if it can't be applied to the 1.0.x branch it should be applied to
the trunk ONLY.

Of course, both the branch and trunk would have their own CCNetLive project=
s.

At some point, we will decide that the trunk should be used to produce
a published release. At that time we will stabilise the trunk and
retire the 1.0.x release branch.

Any thoughts?

Cheers,

Mike

--=20
mike roberts | http://mikeroberts.thoughtworks.net/ |
http://www.thoughtworks.com/

Hi=20All

Long=20e-mail=20ahead,=20sorry!

I've=20just=20upgraded=20to=201.0=20RC1=20and=20the=20CVS=20useHistory=20o=
ption=20is=20now
broken=20for=20me,=20details=20follow:

Things=20start=20well=20with:

19/08/2005=2014:19:52:=20[PN2:Info]:=20Get=20changes=20in=20working=20dire=
ctory:
e:\misc\sources\pnwtl

This=20runs:=20cvs=20history=20-x=20MAR=20-a=20-D=20"2005-08-11=2022:12:50=
=20GMT"

The=20result=20looks=20like=20this:

>M=202005-08-14=2020:59=20+0000=20ssteele=201.6=20=20=20pntabs.cpp=20=20=20=
=20=20pnwtl
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20about.xml=20=20=20=
=20=20=20pnwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20help.bat=20=20=20=20=
=20=20=20pnwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20help.xml=20=20=20=20=
=20=20=20pnwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20htmlhelp.xsl=20=20=
=20pnwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20navigation.xml=20p=
nwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-16=2021:22=20+0000=20ssteele=201.1=20=20=20bookmarks.png
pnwtl/doc/help/images=20=20=20=3D=3D=20<remote>
>M=202005-08-17=2020:10=20+0000=20ssteele=201.54=20=20tools.cpp=20=20=20=20=
=20=20pnwtl
=3D=3D=20<remote>
>M=202005-08-17=2020:10=20+0000=20ssteele=201.33=20=20tools.h=20=20=20=20=20=
=20=20=20pnwtl
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.2=20=20=20help.bat=20=20=20=20=
=20=20=20pnwtl/doc/help
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.2=20=20=20htmlhelp.xsl=20=20=
=20pnwtl/doc/help
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.2=20=20=20navigation.xml=20p=
nwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-17=2020:12=20+0000=20ssteele=201.1=20=20=20dbcatalog.xml=20=20=
pnwtl/doc/help
=3D=3D=20<remote>
>A=202005-08-17=2020:12=20+0000=20ssteele=201.1=20=20=20pn2.chm=20=20=20=20=
=20=20=20=20pnwtl/doc/help
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.7=20=20=20pn2.iss=20=20=20=20=
=20=20=20=20pnwtl/installer
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.125=20mainfrm.cpp=20=20=20=20=
pnwtl
=3D=3D=20<remote>
>M=202005-08-17=2020:12=20+0000=20ssteele=201.7=20=20=20pntabs.cpp=20=20=20=
=20=20pnwtl
=3D=3D=20<remote>
>A=202005-08-17=2020:12=20+0000=20ssteele=201.1=20=20=20htmlhelp.css
pnwtl/doc/help/htmlhelp=20=3D=3D=20<remote>
>M=202005-08-18=2020:26=20+0000=20ssteele=201.26=20=20roadmap.txt=20=20=20=
=20pnwtl/doc
=3D=3D=20<remote>

Then,=20the=20code=20in=20CvsHistoryCommandParser.ParseOutputFrom=20builds=
=20a=20list
of=20changed=20directories:

19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20.
19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20doc\help
19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20doc\help\images
19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20installer
19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20doc\help\htmlhelp=

19/08/2005=2014:19:54:=20[PN2:Debug]:=20Added=20entry:=20doc

The=20command=20to=20check=20for=20individual=20modifications=20in=20those=
=20directories
seems=20to=20combine=20the=20relative=20path=20with=20the=20full=20disk=20=
path=20of=20the
project:

19/08/2005=2014:19:54:=20[PN2:Info]:=20Checking=20directory
e:\misc\sources\pnwtl\.=20for=20modifications.
19/08/2005=2014:19:54:=20[PN2:Debug]:=20Attempting=20to=20start=20process
[c:\program=20files\tortoisecvs\cvs.exe]=20
in=20working=20directory=20[e:\misc\sources\pnwtl]=20with=20arguments=20[-=
d=20
:pserver:ano...@cv...:/cvsroot/pnotepad=20-q=20log=20-N=20=
-l=20
-b=20"-d>2005-08-11=2022:12:50=20GMT"=20"e:\misc\sources\pnwtl\."]

19/08/2005=2014:21:05:=20[CruiseControl=20Server:Debug]:=20cvs=20[log=20ab=
orted]:
Absolute=20pathname=20`e:\misc\sources\pnwtl\.'=20not=20allowed

By=20taking=20away=20the=20"e:\misc\sources\pnwtl"=20I=20can=20correctly=20=
retrieve
history=20for=20"."=20on=20the=20command=20line:

cvs=20-d=20:pserver:ano...@cv...:/cvsroot/pnotepad=20-q=20=
log
-N=20-l=20
-b=20"-d>2005-08-11=2022:12:50=20GMT"=20"."

I=20removed=20the=20Path.Combine=20from=20GetModificationsUsingHistory=20a=
nd=20this
fixes=20this=20first=20problem,=20I=20then=20get=20the=20history=20back=20=
for=20the=20root
directory.

The=20next=20problem=20is=20that=20some=20of=20the=20directories=20listed=20=
in=20the=20initial
history=20operation=20don't=20exist=20yet=20on=20disk=20(they've=20been=20=
added=20in=20the
last=20commit).=20These=20directories=20are=20doc/help=20and=20doc/help/ht=
mlhelp,=20also
doc/help/images.

cvs=20-d=20:pserver:ano...@cv...:/cvsroot/pnotepad=20-q=20=
log
-N=20-l=20
-b=20"-d>2005-08-11=2022:12:50=20GMT"=20"doc\help"=20

returns=20an=20empty=20string=20for=20me.=20This=20seems=20to=20pass=20ok,=
=20although
obviously=20I=20don't=20get=20the=20history.=20However,=20the=20next=20che=
ck:

cvs=20-d=20:pserver:ano...@cv...:/cvsroot/pnotepad=20-q=20=
log
-N=20-l=20
-b=20"-d>2005-08-11=2022:12:50=20GMT"=20"doc\help\images"

Results=20in=20this:

[CruiseControl=20Server:Debug]:=20cvs=20[log=20aborted]:=20no=20such=20dir=
ectory
`doc\help'
[PN2:Error]:=20Exception:=20Source=20control=20operation=20failed:=20cvs=20=
[log
aborted]:=20no=20such=20directory=20`doc\help'

Does=20this=20work=20for=20other=20people?=20=20I=20wonder=20if=20it's=20a=
=20combination=20of=20the
cvsnt=20client=20and=20the=20cvs=20server?

There=20are=20two=20ways=20I=20can=20see=20of=20solving=20this:

1.=20Ignore=20errors=20in=20the=20second=20set=20of=20history=20checks=20f=
or=20subdirectories,
they=20are=20expected=20if=20there=20are=20new=20directories.

2.=20If=20the=20first=20history=20request=20comes=20back=20signalling=20ch=
anges=20then=20do=20a
CVS=20update=20before=20requesting=20the=20changes=20in=20the=20directorie=
s=20-=20this=20will
get=20history/comments=20for=20the=20new=20directories=20too.

Any=20thoughts?

Simon.

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20MessageLabs.

______________________________________


注册新浪2G免费邮箱（ http://mail.sina.com.cn/chooseMode.html ）

===================================================================

Owen,

Responses inline.

> -----Original Message-----
> From: ccn...@li... [mailto:ccnet-devel-
> ad...@li...] On Behalf Of exo...@gm...
> Sent: 20 August 2005 3:06 pm
> To: ccn...@li...
> Subject: [Ccnet-devel] cctray feedback
> 
> in setting up cctray for ccnetlive in order to do screen captures for
> the web site, i had my first interaction with the new cctray
> application.  based on that experience i have some feedback:
> 
> cctray settings screen
> - in the projects dropdown it would be great to list the projects in
> sorted order, rather than reverse sorted order.  this just much more
> intuitive.  i imagine that there's a sorting bug somewhere.

Sorted rather than reverse sorted sounds very sensible ;)  It's probable
that that list is not sorted at all, and reverse order was just how ccnet
server returned the list.  I've just added a sort to this list.

> - it would be nice to have the option of adding all projects from
> server.  potentially having an add all button would accomplish this.

Yes. CCNET-489 relates -- I think this should be done sooner rather than
later.

> - i think that the fetch button is unnecessary.  all projects can
> automatically be fetched from the server when the user clicks on
> expanding the dropdown.  having to click fetch button is just an extra
> unnecessary step.

That was what I was originally planning to do.  I added the fetch button
because if you put an invalid server name in the first box, the UI would
hang for 10 seconds or so while it tried to fetch and the timed out.
There is plenty of scope for further improvement on the configuration
screen...

> installation
> - i don't like the fact that cctray now installs itself it a separate
> directory and program group called cctray.  it is a part of
> cruisecontrol.net and should not be confused as being separate IMO.  i
> think that the files should be installed under
> cruisecontrol.net\cctray -- not under a root folder called cctray and
> in a program group under start->programs->cruisecontrol.net->cctray

Agreed.

> what do you think?  if there is support for these items then we can go
> ahead and create some jiras for them.
> cheers,
> owen.
> --
> Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
> CruiseControl.NET - http://ccnet.thoughtworks.com

Cheers
g

I fully agree that CCNET does need a real way to handle dependencies.
The current build-triggering publisher is - to put it mildly -
incomplete dependecy support.

Regarding Vault, we use it for builds that do sometimes run in parallel
without real trouble. I did however notice that performance is really
weak when more than one copy is running.

Maybe I should point out that I use the version without working folders
or other "client-side" options, cleaning the directory before the get;
also the different instances run in completely different directories (do
not overlap).

Leo

> -----Original Message-----
> From: ccn...@li...=20
> [mailto:ccn...@li...] On Behalf Of=20
> Max Metral
> Sent: Freitag, 19. August 2005 15:18
> To: ccn...@li...
> Subject: [Ccnet-devel] Vault, multiple projects, and dependencies
>=20
> So the Vault task seems to have some problem with multiple=20
> instances running at once.  It is almost certainly a Vault=20
> bug, but nonetheless it makes things difficult.  Now, the=20
> reality of the situation is that the projects I have actually=20
> do depend on each other, so even if Vault worked, running two=20
> builds at once is essentially killing the advantages of=20
> having an integration server at all.  I saw that there was a=20
> patch submitted for dependencies, what's the fate of that? =20
> CC.Net definitely needs SOME sort of dependency=20
> representation to be a real integration product, do others agree?
>=20
> Anyhow, Vault logs the following very confusing messages when=20
> running multiple copies (below).  What's confusing about it=20
> is that there's no way to tell which message comes from what=20
> project.  But while it seems like it's saying "some worked,=20
> some didn't", none actually seem to complete the build.  So=20
> my proposed fix, for now, is a "SuspendOtherVaultOperations"=20
> attribute or something similarly named.
> It's disgusting, I know, but I'm not sure what else to do...=20
> I could push it down into the Vault command line, but it's=20
> kind of nice to be able to use a static instead of file locking.
>=20
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <error>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: Exception=20
> of type System.Exception was thrown.
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </error>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <exception>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: System.Exception:
> Exception of type System.Exception was thrown.
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.Login(Boolean=20
> bAllowAuto, Boolean
> bSaveSession)
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.ProcessCommandHistory(String
> strReposPath)
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </exception>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <result=20
> success=3D"no"
> />
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </vault>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <vault>
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <history />
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <result=20
> success=3D"yes" />
> 8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </vault>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <vault>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <error>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: Exception=20
> of type System.Exception was thrown.
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </error>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <exception>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: System.Exception:
> Exception of type System.Exception was thrown.
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.Login(Boolean=20
> bAllowAuto, Boolean
> bSaveSession)
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.ProcessCommandHistory(String
> strReposPath)
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
> VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </exception>
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <result=20
> success=3D"no"
> />
> 8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </vault>
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference &=20
> EXPO September 19-22, 2005 * San Francisco, CA * Development=20
> Lifecycle Practices Agile & Plan-Driven Development *=20
> Managing Projects & Teams * Testing & QA Security * Process=20
> Improvement & Measurement * http://www.sqe.com/bsce5sf=20
> _______________________________________________
> Ccnet-devel mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-devel
>=20

I was reading the thread:

http://sourceforge.net/mailarchive/message.php?msg_id=11501376

in which Owen kind of hints that cc.net might move over to .netopenmail 
for sending emails. Has this been done? I've been configuring cc.net at 
home for a hobby project and the absolute easiest way to publish the 
build reports is through email. So I was kind of bummed when I couldn't 
get it to work at all (it kept crashing in the CDO component, complained 
it couldn't contact the mailserver... bah, lying of course :)

As a proof of concept, I've attached some code to EmailGateway.cs that 
shows how to send email through DotNetOpenMail instead of the CDO 
component (based off the  1.0 RC1 codebase). Seems pretty 
straightforward. I'm no C# wiz though, so consider yourself warned. If 
anyone wants to integrate it into the main source trunk, go ahead :) The 
comment below needs attention though, one should probably do a:

(python code)

for recipient in string.split( to, ", " ):
    emailMessage.AddToAddress(DotNetOpenMail.EmailAddress(recipient))

just to make sure that we can send to multiple recipients correctly. All 
in all, it seems pretty easy and would probably help people setting up 
successfully a server that can email results.

Cheers,
Jim Tilander

--- publishers\EmailGateway.cs ---

using System;
using System.Web.Mail;
using DotNetOpenMail;

namespace ThoughtWorks.CruiseControl.Core.Publishers
{
    public class EmailGateway
    {
        public virtual string MailHost
        {
            get { return SmtpMail.SmtpServer; }
            set { SmtpMail.SmtpServer = value; }
        }

        public virtual void Send(string from, string to, string subject, 
string messageText)
        {
            DotNetOpenMail.EmailMessage emailMessage = new 
DotNetOpenMail.EmailMessage();
           
            emailMessage.FromAddress = new 
DotNetOpenMail.EmailAddress(from);
           
            // NOTE: Do we need to split the incoming string "to" by the 
value ", " so that we can add a single address
            //       for each recipient?
            emailMessage.AddToAddress( new 
DotNetOpenMail.EmailAddress(to) );
            emailMessage.Subject = subject;
            emailMessage.HtmlPart = new DotNetOpenMail.HtmlAttachment( 
messageText );
           
            emailMessage.Send( new DotNetOpenMail.SmtpServer( MailHost ) );
        }
    }
}

in setting up cctray for ccnetlive in order to do screen captures for
the web site, i had my first interaction with the new cctray
application.  based on that experience i have some feedback:

cctray settings screen
- in the projects dropdown it would be great to list the projects in
sorted order, rather than reverse sorted order.  this just much more
intuitive.  i imagine that there's a sorting bug somewhere.
- it would be nice to have the option of adding all projects from
server.  potentially having an add all button would accomplish this.
- i think that the fetch button is unnecessary.  all projects can
automatically be fetched from the server when the user clicks on
expanding the dropdown.  having to click fetch button is just an extra
unnecessary step.

installation
- i don't like the fact that cctray now installs itself it a separate
directory and program group called cctray.  it is a part of
cruisecontrol.net and should not be confused as being separate IMO.  i
think that the files should be installed under
cruisecontrol.net\cctray -- not under a root folder called cctray and
in a program group under start->programs->cruisecontrol.net->cctray

what do you think?  if there is support for these items then we can go
ahead and create some jiras for them.
cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

So the Vault task seems to have some problem with multiple instances
running at once.  It is almost certainly a Vault bug, but nonetheless it
makes things difficult.  Now, the reality of the situation is that the
projects I have actually do depend on each other, so even if Vault
worked, running two builds at once is essentially killing the advantages
of having an integration server at all.  I saw that there was a patch
submitted for dependencies, what's the fate of that?  CC.Net definitely
needs SOME sort of dependency representation to be a real integration
product, do others agree?

Anyhow, Vault logs the following very confusing messages when running
multiple copies (below).  What's confusing about it is that there's no
way to tell which message comes from what project.  But while it seems
like it's saying "some worked, some didn't", none actually seem to
complete the build.  So my proposed fix, for now, is a
"SuspendOtherVaultOperations" attribute or something similarly named.
It's disgusting, I know, but I'm not sure what else to do... I could
push it down into the Vault command line, but it's kind of nice to be
able to use a static instead of file locking.

8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <error>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: Exception of type
System.Exception was thrown.
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </error>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <exception>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: System.Exception:
Exception of type System.Exception was thrown.
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.Login(Boolean bAllowAuto, Boolean
bSaveSession)
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.ProcessCommandHistory(String
strReposPath)
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </exception>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <result =
success=3D"no"
/>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </vault>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <vault>
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <history />
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: <result
success=3D"yes" />
8/19/2005 7:52:42 AM: [CruiseControl Server:Debug]: </vault>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <vault>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <error>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: Exception of type
System.Exception was thrown.
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </error>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <exception>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: System.Exception:
Exception of type System.Exception was thrown.
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.Login(Boolean bAllowAuto, Boolean
bSaveSession)
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.ProcessCommandHistory(String
strReposPath)
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]:    at
VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </exception>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: <result =
success=3D"no"
/>
8/19/2005 7:52:47 AM: [CruiseControl Server:Debug]: </vault>

Owen,

> if you want, i can produce some screenshots running against ccnetlive
for
> you.
> cheers,
> owen.

That would be great if you get the chance.  I've tried to describe in the
placeholders at
http://confluence.public.thoughtworks.org/display/CCNET/CCTray what needs
to be in the screenshot. 

Thanks,
g

Hmmm, so the only trick about "UseWorkingFolders" is that it implies
something perhaps more complicated than we've discussed.  If
UseWorkingFolders is true, I would kind of expect the server not to pay
attention the path at all, but to use the working folders set by Vault,
which isn't really what we want probably.  So either we change the name
to something like "TreatAsWorkingFolder" or "UseAsWorkingFolder", or
perhaps that "UseWorkingFolders" setting actually SETS the working
folder, which is perhaps what you'd have to do anyway.  I think there
also is perhaps an additional argument, something like "CleanCheckout"
or "WipeDirectory" which tells your stuff to actually blow the directory
away before a build.  Using UseWorkingFolders=3Dtrue and
CleanCheckout=3Dtrue would be meaningless, but not breaking.

I'm not sure if destpath will delete files, I kind of think it
shouldn't.  But I'll ask on the SG boards.

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Owen
Rogers
Sent: Wednesday, August 17, 2005 8:14 AM
To: ccn...@li...
Subject: Re: [Ccnet-devel] Vault integration and _sgbak directories

On 14/08/05, Max Metral <ma...@ar...> wrote:
> I think you're on the right track, but I think it's somewhat flipped.
> As I understand it:
>=20
> UseWorkingFolders =3D true means: use -merge and -performdeletions, =
but
> NOT -destpath
>=20
> UseWorkingFolders =3D false means: use -destpath only, other two don't
> work

you're right.  that's what i meant :)
i've created a new issue for this:
http://jira.public.thoughtworks.org/browse/CCNET-511

do you like the name for the property: UseWorkingFolders?  i'm
assuming that true is the appropriate default value.

if UseWorkingFolders is false, is it necessary to clear the destpath
folder for each build to prevent growing _sgbak directories?  or are
these directories only created in the working directory.  will Vault
prune/remove files/folders that have deleted from the repository when
getting source using destpath?

cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

Richard,

 

That sounds great.  I hope I'll get time to apply it this weekend.

 

Cheers

g

 

  _____  

From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of Foster,
Richard - PAL
Sent: 16 August 2005 10:00 pm
To: ccn...@li...
Subject: [Ccnet-devel] Patch - Allow sorting by columns in CCTray Multi,
and added "Last Build Time" column.

 

Greetings all, 

I finally got fed up with not having the last build time column available
in CCTray. Sure, 90% of the time it's irrelevant - you're more likely to
be interested in when it's going to build next, but it is sometimes useful
to know that a build was triggered when you expect (especially if you are
interrupted by someone coming in and asking questions just when the build
is about to be triggered).

I also wanted to be able to sort the projects (specifically by next build
time, but also occasionally by last build time), so the attached patch
adds that too. Unfortunately, there is a problem. It appears that the sort
is not reapplied when the project status changes. If anyone can suggest
the best way to accomplish that, I will happily implement it. All the
options I came up with so far are things that don't smell so good to me!

Regards, 
Richard 

<<ClickColumnToSortPlusLastBuildTime.patch>> 

On 17/08/05, Ryan Cromwell <rya...@gm...> wrote:
> CCTray 1.0 is significantly better.  I have a usability suggestion - a Bu=
ild
> Server/Project tree to select from rather than a dialog with a drop down.=
=20
> We have 50+ project being built and that continuously grows.  It is too m=
uch
> to add all the first time and as a CM lead you need to know when there ar=
e
> problems.=20
>  =20
> Also, auto-adding new projects to the selected list would be very useful,
> though not imperative.=20

thanks for the feedback, ryan.  i've created a new jira for each of these:
http://jira.public.thoughtworks.org/browse/CCNET-512
http://jira.public.thoughtworks.org/browse/CCNET-513

+1 on the auto-adding new projects.  that would be nice.  or at least
providing that option on the add screen.

i don't think that either of these will be implemented before the 1.0
release.  if anyone wants to take a stab at implementing these, please
let graham know.

cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

On 17/08/05, Graham Tackley <GTa...@th...> wrote:
> The page really needs some realistic screenshots.  The project names we'v=
e
> got here are confidential, so I'm not in a position to just screenshot
> those. I could set up a set of dummy servers and projects but I'm pushed =
for
> time at the moment so it's going to be a while before that happens.=20

if you want, i can produce some screenshots running against ccnetlive for y=
ou.
cheers,
owen.

--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Ryan,

 

Both are very good suggestions.  Owen has already beaten me to create JIRA
issues http://jira.public.thoughtworks.org/browse/CCNET-512 and
http://jira.public.thoughtworks.org/browse/CCNET-513 to cover.

 

Another alternative would be to switch the drop down to a list box, with
ability to multi-select, which would be easier to implement ;) and I think
provide the same functionality you're after.

 

g

 

  _____  

From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of
rya...@gm...
Sent: 17 August 2005 6:41 pm
To: ccn...@li...
Subject: [Ccnet-devel] New CCTray

 

CCTray 1.0 is significantly better.  I have a usability suggestion - a
Build Server/Project tree to select from rather than a dialog with a drop
down.  We have 50+ project being built and that continuously grows.  It is
too much to add all the first time and as a CM lead you need to know when
there are problems. 

 

Also, auto-adding new projects to the selected list would be very useful,
though not imperative.

CCTray 1.0 is significantly better. I have a usability suggestion - a Build=
=20
Server/Project tree to select from rather than a dialog with a drop down. W=
e=20
have 50+ project being built and that continuously grows. It is too much to=
=20
add all the first time and as a CM lead you need to know when there are=20
problems.
 Also, auto-adding new projects to the selected list would be very useful,=
=20
though not imperative.

SGkgR3JhaGFtCgppdCdzIG5vdCBsaWtlIHBlcmZlY3QgYnV0IGF0IGxlYXN0IGl0IGNhbiBiZSBz
b21lIGtpbmQgb2YgdGVtcG9yYXJ5IApzY3JlZW5zaG90OiBJJ3ZlIGJsdXJyZWQgdGhlIG5hbWVz
IG9uIG1pbmUgOgpodHRwOi8vd3d3LmRvdG5ldGd1cnUub3JnL2Jsb2dzL3RiYXJyZXJlLz90aXRs
ZT1jY3RyYXltdWx0aSZtb3JlPTEmYz0xJnRiPTEmcGI9MQoKcmVnYXJkcwoKVGhpYmF1dAoKMjAw
NS84LzE3LCBHcmFoYW0gVGFja2xleSA8R1RhY2tsZXlAdGhvdWdodHdvcmtzLmNvbT46Cj4gCj4g
IEkndmUgc3RhcnRlZCB1cGRhdGluZyB0aGUgQ0NUcmF5IGRvY3VtZW50YXRpb24gYXQgCj4gaHR0
cDovL2NvbmZsdWVuY2UucHVibGljLnRob3VnaHR3b3Jrcy5vcmcvZGlzcGxheS9DQ05FVC9DQ1Ry
YXkgZm9yIHRoZSBuZXcgCj4gY2N0cmF5IChmb3JtZXJseSBrbm93biBhcyBjY3RyYXltdWx0aSku
Cj4gCj4gIFRoZSBwYWdlIHJlYWxseSBuZWVkcyBzb21lIHJlYWxpc3RpYyBzY3JlZW5zaG90cy4g
VGhlIHByb2plY3QgbmFtZXMgd2UndmUgCj4gZ290IGhlcmUgYXJlIGNvbmZpZGVudGlhbCwgc28g
SSdtIG5vdCBpbiBhIHBvc2l0aW9uIHRvIGp1c3Qgc2NyZWVuc2hvdCAKPiB0aG9zZS4gSSBjb3Vs
ZCBzZXQgdXAgYSBzZXQgb2YgZHVtbXkgc2VydmVycyBhbmQgcHJvamVjdHMgYnV0IEknbSBwdXNo
ZWQgZm9yIAo+IHRpbWUgYXQgdGhlIG1vbWVudCBzbyBpdCdzIGdvaW5nIHRvIGJlIGEgd2hpbGUg
YmVmb3JlIHRoYXQgaGFwcGVucy4KPiAKPiAgSWYgYW55b25lIGlzIGluIGEgcG9zaXRpb24gdG8g
cHJvZHVjZSBzY3JlZW5zaG90cyAobm90IGNvbnRhaW5pbmcgCj4gY29uZmlkZW50aWFsIGluZm9y
bWF0aW9uKSB0byBmaWxsIHRoZSBwbGFjZWhvbGRlcnMgYXQgdGhlIGxpbmsgYWJvdmUsIGl0IAo+
IHdvdWxkIGJlIHZlcnkgbXVjaCBhcHByZWNpYXRlZC4gUGxlYXNlIHNlbmQgdGhlbSB0byBtZSBv
ZmYtbGlzdC4KPiAKPiAgQW5kIG9mIGNvdXJzZSBpZiBhbnlvbmUgaGFzIGFueSBjb21tZW50cyBm
b3IgaW1wcm92aW5nIHRoZSBjY3RyYXkgZG9jcywgCj4gcGxlYXNlIHJlcGx5hQo+IAo+ICBnCj4g
IAoKCgotLSAKW2Jsb2ddIGh0dHA6Ly93d3cuZG90bmV0Z3VydTIub3JnL3RiYXJyZXJlCg==

I've started updating the CCTray documentation at
http://confluence.public.thoughtworks.org/display/CCNET/CCTray for the new
cctray (formerly known as cctraymulti).

 

The page really needs some realistic screenshots.  The project names we've
got here are confidential, so I'm not in a position to just screenshot
those. I could set up a set of dummy servers and projects but I'm pushed
for time at the moment so it's going to be a while before that happens.

 

If anyone is in a position to produce screenshots (not containing
confidential information) to fill the placeholders at the link above, it
would be very much appreciated.  Please send them to me off-list.

 

And of course if anyone has any comments for improving the cctray docs,
please reply.

 

g

On 14/08/05, Max Metral <ma...@ar...> wrote:
> I think you're on the right track, but I think it's somewhat flipped.
> As I understand it:
>=20
> UseWorkingFolders =3D true means: use -merge and -performdeletions, but
> NOT -destpath
>=20
> UseWorkingFolders =3D false means: use -destpath only, other two don't
> work

you're right.  that's what i meant :)
i've created a new issue for this:
http://jira.public.thoughtworks.org/browse/CCNET-511

do you like the name for the property: UseWorkingFolders?  i'm
assuming that true is the appropriate default value.

if UseWorkingFolders is false, is it necessary to clear the destpath
folder for each build to prevent growing _sgbak directories?  or are
these directories only created in the working directory.  will Vault
prune/remove files/folders that have deleted from the repository when
getting source using destpath?

cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

hi tim,

> modifications =3D historyParser.Parse(comments, result.StandardOutput,
> from.LastModificationDate);
>=20
> Which leads to a NullReferenceException the first time a project is modif=
ied.

this is fixed in build 1065.
cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com