What other visualizations would you like to see?
What other visualizations would you like to see? Have you seen visualizations that you think would be useful for BVC? If so, post some screenshots or describe what you would like to see.
Follow this discussion to get notifications on your dashboard.
-
Inappropriate?When the build is broken, include all the people who have made modifications to the build --> so you know who to contact.
I would like to take a look at the code, but I'm not able to get it, are you sure the url works? I get a Does not Exist error (there is a space just before bigvisiblectruise-read-only) -
Inappropriate?I'd like to see that as well. The issue currently is that the xml that is returned from the cruise instance doesn't provide this information. It's possible to get this from the remoting endpoint in CCNet, but as far as I'm aware, this isn't available from the other cruise implementations (non-.Net).
I'll dig into this a bit and see what else I can find. This feature has been requested before.
As far as the url goes to the repo, it's a command-line url that google publishes. It should be fine from the commandline. If you're using tortoise, use http://bigvisiblecruise.googlecode.co.... -
I use tortoise svn, and got the following error :
Checkout from http://bigvisiblecruise.googlecode.co..., revision HEAD, Fully recursive, Externals included
Server sent unexpected return value (400 Bad Request) in response to REPORT
request for '/svn/!svn/vcc/default'
Finished!
Can you give me some help on this?
Concerning the other CruiseControl versions, I'll take a look also,
we can always wrap it in a try catch block if it neads be -
Inappropriate?I'm not sure what that error message would be. I just pulled over a different machine, downloaded tortoise and did a checkout with the command above and it seemed to work fine (with http://bigvisiblecruise.googlecode.co...).
Regarding showing the last user that committed a change, we use this information, but we just use the information from cctray. So, we use BVC simply for big visibility and cctray when we need more information.
Maybe the best way to have access to see the last checkout is simply to launch the dashboard from one of the build blocks that are show in the visualization. -
I got the code now (probably there was a network problem or so). I am looking at the code now, keeping you posted -
Inappropriate?For the moment there is no way to get this data from the dashboard as xml, I'll look into the exposing of this data first, afterwards it should be easy to visualize it.
I’m confident
-
Sounds good. I'm updating the code fairly frequently right now, but mostly just trying new stuff out.
I also want to write a "hand-drawn" visualization and then do some cleanup and announce 1.0 (likely by the end of next week). -
Inappropriate?Exposing the messages like 'XXX is fixing the build' is not a problem,
I have a patch for this ready for CCNet (minor upgrade), but since the 1.4 release is imminent, I doubt if it will be included. But maybe I can get it through, there will be a 1.4RC1, so there is a good chance that in the 1.4 final it will be included. Once this patch is in CCNet, I will make a patch for bvc to use this extra stuff
Is it handy that the buildstage is also exposed?
this can be a very long string (xmldata), and I doubt if BVC is the right tool to visualize this information.
I can also set a tag in the xmlstatusreport to identify which CCtype is queried, like ccnet, cc.rb, ..., but maybe it is better to set this in BVC. One knows to which kind of server one is looking. What do you think?
I’m confident
-
That's great. Thanks for the help there.
I think XmlStatusReport.aspx is only exposed from .rb and CCNet and that it's a different url for the java cruise. My code changes that in the trunk right now break on anything that doesn't expose XmlStatusReport.aspx (at least if you use the settings dialog instead of the config file) because of a converter I added for usability-sake.
Overall, I'd like to keep it where you never have to specify which version of cruise is running on either end. Overall, it really shouldn't matter as long as the xml exposed is consistent. As far as I know, this is currently the case. -
Inappropriate?I've added 2 smal patches to the issue tracker in google codes,
if you want patches to be supplied in a different way, let me know.
I’m happy
-
Inappropriate?I made a change to CCNet to expose the messages, so the statusreport also has this. These messages are used for communication between teammembers. For the moment the only item foreseen is XXX is fixing the build.
I've got BVC updated to display this data. I'f you're intrested, let me know and I will suply the patches. The other CC's are not affected by this update.
I’m happy
-
Sounds great. Go ahead and submit a patch when you get a chance.
I'll apply it before I do the 1.0 release (and just have it fail silently for now).
Thanks!
-Ben -
Sounds great. Go ahead and submit a patch when you get a chance.
I'll apply it before I do the 1.0 release (and just have it fail silently for now).
Thanks!
-Ben -
Inappropriate?Another visualisation method than a stacked frame, when the buildserver has 20+ projects, the text is way to small to read. There should be visualisation which shows the projects one by one. So first show project 1, wait 5 seonds, show project 2, ... It may be in carousel mode, but this is not necessary ;-)
Also an option to show only broken projects could be nice in this visualisation.
I’m happy
-
I've thought about that as well. There should be a good story for this. -
I've thought about that as well. There should be a good story for this.
Loading Profile...
EMPLOYEE


