Hudson is a great tool, and the emails it sends about failing builds are a great help. However, it can only do this if Hudson itself is in a working condition. It is able to report problems with its own executors like low disk space, unsynced clocks etc. on the web interface, just as it reports build problems, but I couldn't find an option to send email alerts about these. Yet it would be so useful, and seems so logical that this feature should be there.
Am I looking at the wrong place to fix this? Is there another solution to learn about problems with executors without having to poll the web interface every now and then? Am I missing something?
Did you check all of the plugins?
Did you ask on the http://wiki.hudson-ci.org/display/HUDSON/Mailing%20List ?
Personally, much as I love Stack Overflow, I only use it after I have exhausted more dedicated possilities such aa a dedicated foru, mailing lists, emailing the author(s)/maintainer(s) ..
Sorry.
Btw, I have been using Hudson for years and and say that there is - IMO _ mothing better.
As a last resort, maybe you can hack the source code? This sounds like a reasonable feature so I am sure that your code would be slipstreamed into the main build; failiing that, package it as a plug-in
Have a look at the remote API from Hudson. http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API
You can use it to query the statuses you want programatically. You can also file your request as a hudson issue or document it with the The new emailer plugin
Related
My team uses the Radiator View plugin for Jenkins for fast feedback on the build status of a few different projects. One thing we discussed that would be helpful is if the SVN revision number were included in this view. After only a quick Google search, I haven't found a clear answer on whether this plugin is configurable or not; does anyone know if there's a straightforward way to add this information?
I dont think there are customizable figures there but what you can do is, pull down the source and get the revsion numbers for all the failing builds, you will have to write the code yourself, but from what I can see there is no way of doing this with the configuration options.
What you might want to try if you just need to get that information is the recent changes on the build page of the recently broken build.
Goodluck.
Can I ask why it would be helpful to have the svn revision number on display? As far as I understand it, a build radiator is supposed to 'radiate' meaningful information into the room. The svn number is fairly meaningless unless you can look up the number in the repository, in which case you could have just looked up the revision number on Jenkins anyway.
I'm just guessing, and do correct me if I'm wrong, but I suspect that your real desire is to have some way of quickly working out who might be responsible for a failing build. If this is the case, then processing check-in comments and displaying pictures of the users involved is a far more effective way of getting developers to react to failing builds. I've experienced this first hand at my company.
With this in mind, I have developed a standalone build radiator webapp that talks to Jenkins over its REST API. CI-Eye is trivial to set up, and will probably give you better results in the workplace than the Radiator View plug-in. Give it a try, and let me know what you think -- I'm quite actively improving it, and welcome any feedback.
CI-Eye is free and open source -- see the CI-Eye wiki for more details.
We are working in a CI environment, with Enterprise Cruise running our builds. Developers all have CCTray installed locally to notify us if a build breaks.
CCTray has a menu option Volunteer to fix build that you can use to let your team know that you are fixing the build. However this doesn't work in our environment (reasons: Fix build not currently supported on projects monitored via HTTP).
So the question is - does anyone have a technique that they use in their team that allows someone to indicate that they are fixing a broken build?
For me, Continuous Integration is not only about tools, but also about practices. One of them is the responsibility. In others words, the one who breaks the build is also the one who will fix it!
Shooting "I take it guys" is my prefered. ( in addition of the responsability romaintaz describe )
We send an email to the Developer's mailing list to let everyone know you are taking ownership of the build break.
We're co-located, we all run cctray, and when the build breaks we have an audio alert (red alert from the Starship Enterprise). When it breaks we all shout "who broke the build"! Once we figure out who broke the build we harhass them until they tuck their tail between there legs, do that stupid embarassed laugh, and volunteer to fix the build.
It's worth noting that things that aren't monitored by the build and tests can change on a CI box. For example: maybe someone went onto the box and changed a permission. Then when the next checkin is made it looks like the person that made the checkin broke the build when really it was the person that made the manual change without telling anyone.
On the volunteer thing, tools can help but verbal face to face communication is still king.
The onus is usually on who broke the build with their checkin. That's often obvious, even with multiple checkins from different individuals. After that there's a bit of negotiation if the build remains broken. Not particularly scientific or rigorous, but it seems to work.
If the build brokes, then in CCtray there is an option for "Volunteer to fix the build".
And it tells automatically to all the developers who is fixing the build
I use Trac to track my bugs related to my php web application. Tough, mainly I register feature request/tasks in trac. Do you find it a good practice, btw?
It's very handy, becouse I can track my tasks via Eclipse/mylyn, comment and fix them. I like trac very much, but I'm afraid of a lot of loosley coupuled tasks, that almost looks like bugs.
Is there a way (or other tracker system) to store my tasks hierarchically? I mean:
Store module (feature)
Add product (feature)
List product (feature)
Delete product (feature)
Unable to delete no name product (Bug)
Other Module.. etc.
Edit: Is there any other good practice where and how to store tasks hierarchically?
Fogbugz has tasks & subtasks, I haven't worked with this feature enough to see if it would help though. You could play around with the hosted eval version, though. (For my taste, the web interface feels to sluggish for me to use it - but I have that problem with lots of things.)
I recognize your problem as one of my own, however I'd prefer to use separate lists/hierarchies.
[update]
At the moment, I am using the starring and heavy search/filtering, and for "keeping my head on" with quickly incoming tasks or larger refactors, I use pen&paper for temporaries (A5 ringbound booklet) and ToDoList for semi-permanents.
JIRA also has this functionality + it's almost free ($10 for 10 users).
See here, and here.
And yes... I think this is good practice, just don't over exploit it.
And this is how it looks like:
You could stick with Trac and look for desired functionality in http://trac-hacks.org/
That looks like what you want (there might be others I just did a fast search):
http://trac-hacks.org/wiki/MasterTicketsPlugin
http://trac-hacks.org/wiki/TracTicketDepgraphPlugin
We are using a couple of plugins from http://trac-hacks.org/ with 0.11 and they work great.
Have a look at the Roundup Issue Tracker.
Years ago, before Trac came out, I wrote several user support and development trackers with it. It's very, very easy to customize the database schema and create new html page templates.
To manage hierarchic tasks, you basically define an IssueClass-based task class that way:
task = IssueClass(db, "task",
dependson=Multilink("task"), # here, you link tasks to other tasks
assignedto=Link("user"),
keyword=Multilink("keyword"),
priority=Link("priority"),
status=Link("status"))
There's a recipe in the Roundup documentation that shows you how to create "blockers" issues, meaning that you can't close an issue if one of its linked issues is not closed:
http://www.roundup-tracker.org/docs/customizing.html#blocking-issues-that-depend-on-other-issues
TargetProcess supports the hierachical structure you want. It's an agile Software Project Management Software, however it features highly customizable development processes and can therefore be used for Waterfall or Kanban/Lean processes also. The deepest hierachical structure you can have goes like this:
Program
Project
Release
Feature
User Story
Task
There is a free community edition which you can use for up to 5 users. TP has a lot more than just task tracking, it features Bug Tracking, Q&A, Help Desk, Time Tracking...
You mind look at GoPlan: http://goplanapp.com/.
It is fully functional project management web application, which provides to create a hierarchy of tasks. There is a free plan, so You can check it easily. You can have task tree with any depth.
Difference between this tool and Trac is that GoPlan is not directed to maintain source code, but a project itself, so You cannot close Your tickets from Eclipse. Unfortunately tasks do not have resolutions (tickets have, but they cannot be arranged in hierarchy), but I think it is not a kind of disadvantage that discourages from using this application.
You've probably already thought of this, but I'll put this in just in case. In Trac, I oftentimes organized tickets as sub-tasks, at least through convention by simply placing links to those tickets in the description of the master ticket. What's nice about this is that closed tickets are shown as crossed out, so you can get an idea of the status of the sub-tickets at a glance. OK, so it's not setting up a hierarchy, but it's a flexible system that also allows you to set up other relationships; for example you can also reference another ticket as a dependency or related issue.
Some of the requirement management tools out there support hierachies, e.g. CaliberRM from Borland. However, these are heavyweight and commercial. This only makes sense if you have some significant amount of information to handle.
OK, so we all know the daily build is the heart beat of a project, but whats the single best way of automating it?
We have perl scripts wrapping our pipeline which includes ClearCase, VS2005 (C++), Intel FORTRAN, Inno setup. We use cron jobs on UNIX to schedule the build, and host a simple Apache web server to view and monitor the build. All in all its rather complex, I would like to know whats the best off the shelf solution that people use?
And yes I did say FORTRAN no escaping it sometimes, it works, no point doing a huge re-implementation project for some tried and tested FEA code that just works.
A new one to me that I've heard is quite slick is hudson - also with MSBuild support.
We're in the process of implementing CC.Net. So far it seems like it would fit your model pretty well.
Out of the box it offers automated building, results tracking and notification. I'm not sure how detailed the build-in-progress monitoring is though.
There are many tools that specifically handle this:
Cruise Control
Hudson
Continuum
The tools have out of the box support for the most common build types. They all also support some sort of "run this script" type build process.
In the end you should use the nicer build tools (MSBuild, Ant, Maven, Make, ...) where you can and fill the gaps for the odder tools with custom scripts. The automated build can just invoke these in the right order.
Here is the best resource we found to help us pick a Continuous Integration tool. We have been evaluating 5 or 6 tools on this page.
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
We use TeamCity - but then its a simple C#/Java development - maybe your pipeline can done via scripts it can drive?
I have had success using Visual Build Pro.
CC.NET is very powerful. Used it and was really happy about it. Even the status icon in the systray. It's a small detail, but it gives you a good overview of the project's "health". You immediately feel motivated to fix the tests when you see it red.
Now we use a self-baked series of scripts. Since we write Python, compilation is non-existant, so the only problem is running the tests.
If you're working with Visual Studio, be sure to check out Team Foundation Build to see if it will suit your situation.
It looks like Buck Hodges' blog post on the VS 2008 version is a good resource, too.
I know this is a really old question, but it's still coming up in searches, so someone should mention Jenkins - the open source continuation of Hudson.
From the Jenkins wiki:
Among those things, current Jenkins focuses on the following two jobs:
Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.
It was originally built with Java in mind, so it integrates well with lots of other Java tools, but you can use it with any language, including all those mentioned by the OP.
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.