Play sound when automated build fails - continuous-integration

We are using TeamCity v4 and NAnt for continuous integration builds on a server in our work area. We would like to have the build server play an mp3 or wav file when the build fails. Anyone has any ideas around this?

Install the plugin that lets you use CCTray with TeamCity, then install and configure CCTray (on the build server itself if that's where you want the sound to play) and enable sound notifications. I found a blog entry on how to do this.
Alternately, you could rig your build server up to a lava lamp to display your build failure status :D
Edit: I've searched around and it seems like there's no simple way to do this using existing TeamCity build failue hooks. You could write a plugin to do it, but failing that it seems the above CCTray-based option is the best and cleanest.

Related

Bitbucket Pipelines - Is there a way to see a build monitor?

We are starting to use Bitbucket Pipelines after previously using Jenkins as our CI server.
The only thing that's missing now is a build monitor, something similar to the Jenkins Build Monitor seen here: link
Does anyone know of an equivalent for Pipelines? I suppose I could always create my own using the Bitbucket Repositories API and an open source build monitor framework like this, but I'd rather not do that unless I have to.
Thanks!

Automate Maven Scripts

I have a series of Maven Scripts which are to be run in Linux Platform for doing Reversion and Lableing for my Project. I would like to know what Building Tools i can use to automate the Maven Scripts in the Linux Platform?
Also say suppose I have got some error while doing the Reversioning / Lableing of the code. How can the Automate tools Handle these scenarios.
Please let me know of the effective tools and I would certainly reply back whether those do help me out or not!
I would suggest leveraging a "job" coordinator such as Jenkins or Cruise Control to manage any and all of our automation. Maven is natively supported and understood by these tools. An agent will reside on your server, and do the bidding of your coordinator.
Jenkins is a good solution to automate maven build:
easy to install
easy integration with maven
allow you to automate simple task after build failure/success like sending email
many plugins including this one that allow you to do more complex task after a build failure (or build success)
Any one of this
Jenkins
Hudson
Atlassian bamboo
TeamCity
After using LuntBuild, Jenkins and teamcity I can say without a doubt that TeamCity is by far the superior choice.
I think it's free for a small configuration (3 agents, and up to 10 build configurations).
It very easy to install and configure, compatible with most source control systems.

What should I use for continuous integration given my circumstances?

I'm developing a project in C# using VS2010. I'm using svn 1.7 for my version control. What I want is a (FREE) tool that runs on the build server and checks for fresh commits. If the commit breaks the trunk then I want email notifications sent (I have a sendmail openbsd server on the network I can use). I also want this tool (or another tool) to run all my MSTest tests periodically and send emails if there is a failed test.
Any suggestions? I already built my own crude windows service to check for failed builds. But this was before I heard that tools for this sort of thing already exist. I could easily have this thing run all my tests with mstest.exe and then parse the xml results files, but I'm wondering if my time would be better spent just installing and configuring a proper tool for all of this.
There will be at most 4 developers.
Thanks in advance for the help!
I have some experience with TeamCity and Hudson/Jenkins.
I found TeamCity fairly easy to setup and it seems to meet your needs of:
MSTest integration out of the box
Email notifications
TeamCity is free for up to 20 build configurations and has an easy to use Web/GUI interface.
Have a look at CruiseControl.Net
built in support for Subversion
no limits on number of build configurations
email notifications using the 'Email Publisher'
web interface and desktop build notifications via CCTray

Personal builds with Hudson continuous integration server

I'm thinking of using Hudson as my continuous integration server. In the past i have used the Pulse build server from Zutubi which had a nice feature called personal builds that allows a user to test a changelist on the Pulse server before committing the code. Does anyone know if Hudson offers this as either a built in feature or via a plugin?
From the answers on other questions on stackoverflow, there might be a way to emulate this feature with git and Hudson. Don't know if that might be an option for you.
I have used Pulse for a while and that's one of the things I'm missing. I don't think hudson does that.

Building ONLY Labelled Versions with CruiseControl.net or TeamCity

We're currently using CruiseControl.NET as a continuous integration server for a number of ASP.NET web projects, but we're also evaluating TeamCity.
This is working great for our build server.
What we'd like to setup is a customer facing test server. I'm thinking that when we are happy for our latest development version to be released to the client for test, we could label it in SVN.
I'd then like a second build server to build this version ready for the client to see.
The question is this - is there any way to get either CruiseControl.NET or TeamCity to build only the latest labelled version of the code in a repository?
If anyone has any alternative suggestions, that'd also be greatly appreciated!
You could have a designated location or branch in your subversion repository e.g. \release then point the second TeamCity build server at that.
When your are happy with trunk then overwrite the existing location. The second build server will pick this up, build it, and even deploy it to a test server.
I don't think there's a way to do this directly in TeamCity. You can however configure your build trigger to filter on files and/or users. So, if you touch a given file to indicate release status in addition to or rather than labelling, you can use that.
The trigger filter could be, for example (untested):
+:/ReleaseVersion.cs

Resources