This project has moved. For the latest updates, please go here.

A way of showing multiple buildservers with 1 Cradiator

May 4, 2010 at 8:13 PM
Edited May 4, 2010 at 8:20 PM

I made an enhancement that will allow you to monitor multiple buildservers.
it has also the possibility to create 'views' on 1 buildserver.
You can already use a regex on projectname and category, but this limits you to view 1 set of data.
An alternate solution would be to have a kind of batch file that copies pre-defined sets of exe.config files over the existing one with a sleep interval,
but a native solution is better :-)

For the moment the code is a bit hacky, but here are the main changes involved :

  1. added a MultipleServerWatchFile to the configuration.
    this allows the configuration to be outside of the app.config making it a bit easier. This needs to be reworked.
  2. added a generic list  to ConfigSettings.cs, holding all the data needed for a certain view :
    URL ,SkinName,PollFrequency ,ProjectNameRegEx ,CategoryRegEx
    these reside in a IBaseConfigSetting, and are implemented by MultiServerSetting (object of the added generic list)
  3. on loading the config, the extra file is also read, :-)
  4. whenever the timer expires, I push the next element of the generic list into the properties of the existing ConfigSetting
    --> so just copy over the values, meaning that the impact on existing code is minimal


so after every timer expire, the next item from the multiserver is shown.
making it possible to use 1 LCD screen to visualise a lot of buildservers, views, ...

that is basically it, I can sent a patch if you're intrested

I also added the following minor items :
° added the servername to the projectstatus
° added the lastbuildtime to the projectstatus
° added an option 'showbrokenonly' to the config (and the multiserverconfig)
     when the value is true, the data retrieved from the url is filtered on broken projects only
     --> updated the linq query (working with a StatusToVisibility converter is has side effects)
     todo on this : when there are no bad projects, the screen is just black
                         

Coordinator
Aug 4, 2010 at 6:14 AM

Hi Ruben

Yes, absolutely, a patch would be great.

You could also fork it - I've moved the source code for Cradiator to GitHub - http://github.com/PandaWood/Cradiator

 

Nov 1, 2010 at 9:44 PM

Patch has been uploaded

This patch also could fix the following issue :

MODE: Only show broken

I have made some extra updates in my local code, that go beyond the patch I provide,

and those updates foresee in way to show a smiley (just an image) if all projects are ok.

--> so if you set showOnlyBroken to true, and there are no broken items,

 the image is shown in stead, normally you would have seen a black screen.

 

Let me know if intrested in these updates also

 

Coordinator
Nov 2, 2010 at 2:27 AM
Edited Nov 2, 2010 at 2:38 AM

Thanks

Actually, I just added a Multi-Url feature over the weekend, on the master branch. So I've doubled up. Sorry about that.

Here's the diff, to get a good idea of what I changed - http://github.com/PandaWood/Cradiator/commit/ca392417cd7b68b349bb0ba49e4f6f14ec30e646

(That I can show you this diff is one reason I like to use GitHub)

My Multi-Url feature caters for the scenario we have in our dev room - to basically just monitor 2 (or more) URL's with all projects (and filter a few out). With a reasonably clever Regex, this change does it for us.

I haven't compared your changes yet, from what you've said, your changes are more complicated - but then my change may not quite cater for what you're after?

You've got sort of a multi-url/multi-view switching going on. So looks like your big requirement is to not suffer an increase in the number of projects in the original view? We might want or be able to implement your switching-like feature, as an add-on to what I've done...

But you've also got the ShowBrokenOnly config, which will no doubt make it easier to bring that feature in, than starting from scratch.

Nov 3, 2010 at 7:00 PM
Edited Nov 3, 2010 at 7:16 PM

How do you want to go from here?

you want me to recreate my patch on the latest trunk, incorporating your multi-url?

 

my approach indeed does multi-url / multi-view / whatever you want to call it

Basically :
° all things that 'define' a certain view are set in a new interface IBaseConfigSetting (maybe we should rename that to IViewSetting or so)
    --> sounds, server-regex, projectregex, what kind of wpfcontrol to use (stack, grid, ...)   all those kind of things
° the ConfigSetting for the moment holds the data for the view currently shown on the screen
° whenever the countdown- timer elapses, I copy the data from the next entry in the array to ConfigSetting

your change just has multi url, I monitor a 83 servers (no kidding !), so I need more filtering

as you can imagine, I can not set up around 80 screens, just for monitoring that :-)

 

just noticed : the discussion : "Cradiator Improvements" also has something similar
that user was playing with an importance level, but is stuck on 10 items
my approach allows to define X amount of different views

seems like this is a needed enhancement :-)

Coordinator
Nov 7, 2010 at 9:51 AM
Edited Nov 7, 2010 at 9:53 AM

Thanks for those descriptions by the way, I did read them and find them useful.

In thinking about this, I've taken your patch and had a go at porting it over on the weekend. I did a little refactoring - throwing my immediate thoughts into the pot. I made a branch for it on GitHub - https://github.com/PandaWood/Cradiator/network (multiview)

(BTW I held up on the servername/onlybroken & other changes, until this is finished)

For example, I pulled the code that decided to update the view (based on countdownTimer.Seconds==0) into the ScreenUpdater

And refactored ConfigSettings to do more work surrounding the updating logic (including using a Queue - this is just my fetish against using indexing into Lists)

I incorporated the xml config into the app.config as per below. Notice, I removed the old references to appsettings/URL & ProjectRegEx etc. If I didn't do this, there would be situations where the appsetting/URL would be ignored and sometimes when it wouldn't (eg MultiView or not). To avoid this sort of confusion, the new views/view xml structure is the new, compulsory part of configuring Cradiator.

github-app.config

 

<views>
 <view url="debughttp://ccnetlive.thoughtworks.com/ccnet" 
  skin="StackPhoto"
  project-regex=".*"
  category-regex=".*"/>
 <view url="debughttp://url2" 
  skin="Grid"
  project-regex=".*"
  category-regex=".*"/>
</views>

 

One interesting thing is the MultiUrl feature I worked on earlier works untouched into this MultiView (ie our changes weren't the same & are mutually useful). You can now define multiple URLS (ie space-delimited) in your view/URL. This is the main reason I changed the name of the classes from MultiServerSettings to ViewSettings - to reflect that 1 view may not actually be 1 server.

But I would like to pull your other stuff, including the MultiView skin in later.

Nov 7, 2010 at 5:34 PM
Edited Nov 7, 2010 at 5:50 PM

Nice, this will make Cradiator a lot more appealing :-)

No problems with those refactorings, it is indeed a lot better.
The reason I need a severName regex is that I point the url to 1 dashboard, that gets the information of those 83 servers, makes configuration a lot easier.
Should there be another server added this is automatically shown into Cradiator when I udate dashboard config.

I've also a view that shows a smiley when there are no projects matching the data, this is only used with the ShowOnlyBroken,
and is very helpfull. In those situations I show the SettingName(that's the reason I added that) and the smiley, so you know which view is all ok.
The way for showing the smiley is a bit of a hack for the moment : Whenever I notice that the count of the data is empty, I add a dummy project :
an AllOkProject, with a known name.  In the WPF view I have 2 sections, one that shows the smiley if the name matches the AllOkProject, else the other section is shown.

I could not find another way for the moment, since we're binding on Projects. Should we bind to a master element something like this :

Public Class MasterInfo

   prop bool AllOK
   prop list ProjectData

End Class

Than it would be more elegant, this MasterInfo class could later be extended easily for other needs.

Just contact me if you need more info, code, I'll be happy to provide it .

 

 

Coordinator
Nov 12, 2010 at 1:45 AM
Edited Nov 12, 2010 at 4:24 AM

I merged this feature (multiview) into the master branch on GitHub yesterday - https://github.com/PandaWood/Cradiator

I fixed it so the Settings Dialog can still be used in the case of only 1 view (the default & most common usage, I suspect)

If there's >1 view, then the view-related text-fields (url/regex/skin) become read-only and auto-update along with the view rotation (fun to watch) - but you can still 'Save' the non-view fields. Realistically, I expect most people are editing the config file directly & the Settings Dialog is just for convenience/fun.

I'll probably add this as a release after a bit of a tidy up & then look at adding the ShowBrokenOnly feature.

The best way to contribute now is to fork on GitHub and send a Pull Request.

 

Nov 12, 2010 at 4:33 AM
Edited Nov 12, 2010 at 6:21 AM

OK, I'll try that

 

So you'll do a release first for the multiview, and next add the ShowBrokenOnly ?
Nice, that'll buy me some time :
° this will be my first project with Git, so I'll need to learn that first.
° I'm working at the backlog of ccnet, so most of my time goes to that :-)



with kind regards
Ruben Willems