So, I'm setting up Hudson right now and couldn't be more pleased. However, I need to display a table in the test results page as opposed to the graph it provides. Does anyone know how I would go about doing this?
I guess you'd want to make a custom plugin out of the existing Junit functionality. You can pretty much copy the java files from:
hudson/main/core/src/main/java/hudson/tasks/junit/
and resource files (jellys) from:
hudson/main/core/src/main/resources/hudson/tasks/junit/
to your new plugin (unless you don't want to fork Hudson source). It seems that the files you'd like to fiddle around would be
hudson/main/core/src/main/java/hudson/tasks/junit/History.java (where the graphs are created) and hudson/main/core/src/main/resources/hudson/tasks/junit/History/index.jelly (where the created graphs are shown). From History-class you can pretty easily get a grip on how to fiddle around with TestObjects.
What do you want to display in the table - just the results from the latest build, or the same trend data that the default graph displays ? Either way, I think you'd need to modify the Hudson code to do what you want - see the Hudson Wiki.
Related
I am fairly new to TeamCity and have recently been tasked with creating various builds, which I have done with no real issues.
What I am trying to do now though is include an external text file into the build output.
The external text file will be received from a service call made during the build.
These are my intended build steps:
Check out solution.
Restore packages.
Run tests.
Call web service with a configurable parameter and receive text file back.
Include text file in build.
Deploy.
Steps 1,2,3 and 6 are covered.
What are my options here? I must confess I do not really know where to begin.
I've spent some time today googling but it has been tricky getting the correct search term to return information on what I am trying to achieve.
I've seen some confusing articles on a 'meta runner'.
Any pointers to get me started in the right direction would be much appreciated.
Thanks.
Use a TeamCity command line build step - https://confluence.jetbrains.com/display/TCD9/Command+Line
I assume you are using build steps for all the other steps you listed so this is simply another of those.
The command line process would run somewhere under your checkout folder and thus anything it downloads would be made available as an artifact for your build
I was just looking into referencing css files in a theme, that reside in a different database and I was wondering:
Could I reference a whole theme that resides in a different database as well with "extend"?
The reason behind that is: Would it possible to keep themes in one central database that can be used by all kinds of applications and therefore, if there should ever be changes to the themes, they only have to be changed in one location and not in every application.
Thank you for your responses in advance.
no I don't think this is possible (happy to be wrong if someone else knows it is?)
to keep all your theme files in a central spot, an XspLibrary in an OSGi plugin is a good solution, however it is a steep learning curve if you haven't done this before. The benefit is once you know this technique it opens the door for 'centralizing' other parts of xpages.
you deploy the plugin to each server and each client if using xpinc, and the every nsf can use a theme from that plugin.
there are a few 'getting started with xpages plugins' articles popping up around. check through planetlotus.org (I'll edit this answer later with some links)
once you know how to do an XspLibrary, you can then download the source code of the bootstrap4xpages project on OpenNTF to see how they are serving up their theme from a plugin.
it relies on the Extension library though so if you don't use the exit lib you could reverse engineer the necessary parts of that project too!
this bootstrap project was set up by Phillipe Riand who was the chief architect of XPages, so it should be a good example!
I am halfway through creating a video series on doing a theme from a plugin but have temporarily lost motivation :(. I might finish it sometime this year, if I do I will post a link to it on this answer. in the meantime I am happy to answer any questions you have about it if you want to give it a go.
otherwise, a quick and dirty solution would be put the theme files / CSS / images directly on the file system of the domino server, where the other theme files are. 'Mastering XPages' might have some advice about this but I don't have it with me right now :)
I think the short answer is you won't be able to load just a theme from a different database.
Each NSF has it's own JVM, sitting on top of the server JVM. So you can extend a theme that's sitting on the server, but not one in another NSF.
XPages Single Copy Design loads a theme from a different NSF by effectively loading the template's JVM. So it's the theme, but also all other design elements.
Jesse Gallagher's done some work in OpenNTF Domino API to allow you to load an XPage or Custom Control from another database, but I'm not sure if that would work for a theme.
If you want to design once and use in many, you can add the theme to the server itself. Looks for the OneUI elements to see where you need to store it (or it may be mentioned in Mastering XPages). You can only nest themes to five levels, but you should be fine.
Is there a way to make Jenkins accept and graph test results that aren't binary passes/fails?
I'm writing a performance test for an Open Source project I contribute to. After each successful build, I would like Jenkins to run a bash script I've written, then report as the test result a value I compute during the test. The value would be on the order of 10k, if that matters. The idea is to allow devs to view the historical performance of the codebase, as well as how their commits changed it.
I'm new to Jenkins, but I've Googled pretty hard and found nothing relevant. Links are appreciated, even if you don't have a full answer.
The Plot plugin should be able to do what you need; you can store the test results in csv format and then graph them across all builds.
I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.
Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.
Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.
Issues that need to be respected or clarified;
Manual build of a single brand via Idiot-Proof GUI (choose a git
branch/tag, specify a certain brand, configure the app e.g.
IAP-enabled, server-domainname, etc - will be written to the
info.plist)
In previous manual tests, setting the executable name in
the plist didn't work? Sorry, have forgotten the exact problem..
perhaps was only an Xcode Debug buildconfig problem, not relevant to
a distribution build?
Code-Signing?!? Can the profile be specified
on-the-fly? Some brands need to be built with the customer's own
profile.
My personal feeling: Hudson or CruiseControl + Xcode plugin.
There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?
And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.
So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?
Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).
IMHO you can resolve all issues using different targets of XCode.
Every target will share the code but it could:
be signing with diferent profiles
use diferent plist: this implies having different names..
use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
Build with one click in XCode.
I hope this helps
An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.
See this script as a starting point: https://gist.github.com/catmac/1682965
Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.
My team has a goal to minimize the amount of time that our build is broken.
We use CruiseControl.NET for continuous integration. What I'd like to find out is how best to approach answering the following question:
"In the last {timespan}, how much time has {project-name} spent in a broken status?"
For example:
"Over the last 1 month, how much time has our project spent in a broken status?"
Are there any advanced features of CruiseControl.NET that would facilitate making this information available in some type of a report or somewhere in the dashboard?
Alternatively, how would you approach parsing the xml artifact files to glean this info?
you can use the statistics publisher,
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Statistics_Publisher
and you can display them via project statistics plugin
I see at least two ways to approach this:
You write an external tool which parses CC.NET's XML log files for a project (stored in buildlogs subdirectory by default), calculates statistics and writes a HTML report. This is probably easier to do, but it won't be directly integrated with CC.NET.
You write a CC.NET plug-in to do this. You'll need to do a bit of investigating in this case. My guess the starting point would be to look at the source code of some existing plug-in.
Here are some links about CCNET plugins:
http://www.cruisecontrolnet.org/projects/ccnet/wiki/DevInfo_MakingPlugins
BrekiLabeller - my own plug-in, useful if you want to see how a plug-in can be implemented.
Having had a very quick look at the CC docs, I imagine if you were writing your own Cruise control dashboard, you could consume the RSS feed of build results, parse in all the date times and success/failure states up to your threshold, then sum up the totals.
As for displaying it in a dashboard, I think Cruise Control has a plugin architecture which might help http://cruisecontrol.sourceforge.net/main/plugins.html
So my eventual solution wasn't ideal, but it was easy to do and it works:
I had CC.NET send build emails to an email address (we'll call it build_emails#build_statistics.com). Then I use a ruby script to get the emails via imap and process them to determine our build failure time.
I didn't go the route of directly parsing the xml because I would have had to parse every xml file in the timeframe to build up a timeline and then go over the timeline to make my calculations. It just seemed too complicated to get a simple statistic like this.
I like cc.net, but in this case TeamCity just does this for you. It has lots of other great statistics too. It's free for less than 20 projects.