Re: Combining Builders, Tasks and Publishers?

I think everyone's going to be happy (eventually :) )

The server API *already* has the methods:

void AddProject(string projectConfig)
UpdateProject(string projectName, string projectConfig)
string GetProject(projectName)
DeleteProject(projectName)

..but these aren't fully implemented (or they're implemented a bit nastily)

These are already on the Remoting interface and will be on the Web
Service interface 'Real Soon Now'

The Web App will be 'just one' way of getting projects into a server
and people using it don't have to care about what the underlying
config structure looks like. If somebody else wanted to generate
config outside of CCNet though (with XSL or whatever) and 'squirt' it
straight in via an external interface, that's cool too. The Project
config structure effectively just becomes a 'dynamically typed' part
of the CCNet Server interface.

Now, the tricky bit comes with how the server interprets such calls
(e.g. what happens if someone updates a project while a build is
happening? If you update a project should you check everything out
again?) This stuff is all a little tricker and is one of the main
reasons the automated config code isn't ready yet. Also, only Perforce
supports the Project working directory which also makes things a bit
tricky.

Re: http url's for config. I don't think I want to do this in the
server core (when would it call out to the URL?) , but I don't think
it would be too hard to create an extra Service (as in Service
Oriented Architecture) whose sole responsibilty was to grab configs
from somewhere and inject them into a server, effectively giving the
same behaviour.

Ryan - what were your thoughts about timing of updates? Would such a
service poll URLs on a scheduled basis, or would you want a manual
trigger to update the configs? If the latter, a simple web app would
suffice.

Mike

On Wed, 3 Nov 2004 08:27:23 -0500, Ryan Cromwell
<ryan.cromwell-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote:
> I would disagree.  It is extremely important for a private Config Mgmt
> group, especially in a very dynamic group like contracting/consulting
> firms, to be able to automate the process of generating things like
> the CC.Net config file.  This is why my earlier suggestion for
> supporting http url's as a config path would be such a boon.
> 
> With all of the projects that our company is constantly
> acquiring/starting, we would need almost 1 entire FTE just to manage
> the CC.Net configs.  In my opinion, I'm glad we've avoided the
> complex/NAnt-ish config suggestions for just this reason.  NAnt and
> custom builders, tasks, etc are there for complex features which go
> above and beyond the task of a glorified scheduler and reporting
> engine.
> 
> That said, I really do like the web app a lot for most (+90%) cases.
> 
> On Wed, 3 Nov 2004 09:44:50 -0000, McCarthy, Donal
> 
> 
> <donal.mccarthy-rSpORMHoMvQAvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote:
> > Hi,
> > The preferred way of configuring CCNet should be through the web app
> > going forward.  In that light, the format of the config file seems
> > largely irrelevant.
> >
> > I think efforts should be concentrated on building a UI which is easy to
> > use and allows full configuration of the underlying server (or server
> > farm).  Ease of use is what will distinguish CCNet from other CI servers
> > and allow it to become the de facto standard for CI in the future.
> >
> > However, in the spirit of ease of use, the config files should be
> > strictly versioned and CCNet should support reading old config files and
> > converting them to new file formats automatically as part of any CCNet
> > upgrade process.
> >
> > Regards,
> > Donal
> >


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click