imedo Development Blog

there is no charge for awesomeness

Archive for the ‘continuous integration’ tag

CI output formatter update for Cucumber 0.3.9x

without comments

In the 0.3.9x releases of Cucumber the output generation has been changed in a way which prevents our output formatter from marking scenarios with undefined steps as pending.

Here’s the updated code: imedo_ci_formatter.rb

Popularity: 1% [?]

Written by ehartung

August 10th, 2009 at 3:47 pm

Managing Hudson configurations

without comments

If you have a continuous integration setup which deals with as many projects as our’s does, backups of the configuration files are absolutely mandatory. Even better than making backups is the usage of a version control system like git or Subversion. It enables you to change the configuration files on your local machine and merge these changes with those someone else did using the web interface.

The possibility of changing the CI configuration files locally is especially handy if you have to deal with more than 100 projects on the CI system like we do. Then the search-and-replace tool of a text editor can save you hours.

We are using Hudson which stores its configurations in XML files which we manage in a git repository. Our Hudson master uses a checkout of this repository. For merging the changes done over the web interface into the repository we created a simple Hudson task. This way we have different ways of changing the CI configuration and we have a backup in case our CI system crashes or we need to set up a new one.

Popularity: 1% [?]

Written by ehartung

May 15th, 2009 at 11:20 am

Build monitor for Hudson CI system

without comments

For receiving feedback on the current build status of software projects, a quite useful tool is the Firefox add-on Hudson Build Monitor. It shows the current status of one or more projects on the continuous integration system in the Firefox status bar and is a good addition to email notifications and extreme feedback devices.

In order to react fast developers need feedback on their code changes as soon as possible. At best this would be directly after the piece of code is integrated into the software project. Of course this implies that the developer has tested the code on his machine before.

Continuous integration systems like Hudson are capable of sending emails to the one developer who broke the build as well as to everyone else who needs to be updated on the current status of the build. This is usually enough for smaller software projects, but we are managing more than 100 projects with Hudson. So configuring the email addresses for every single project is too much overhead. Especially since we have cross-functional project teams which only exist for a period of time.

Extreme feedback devices like bear lamps or ambient orbs can solve the feedback problem for one team. But these devices are usually out of sight for product management, quality assurance, and other development teams.

Our feedback device is one screen which shows the status of all projects. Therefore the Hudson Build Monitor replaces the extreme feedback device in our project teams as well as it gives others the possibility to keep track on single projects without watching the screen or the Hudson dash board.

Popularity: 1% [?]

Written by ehartung

May 13th, 2009 at 9:52 am

CI output formatter for Cucumber 0.3

without comments

Not long ago we presented our output formatter for Cucumber (see Cucumber output formatter for continuous integration ). Meanwhile Cucumber 0.2 and 0.3 have been released and the API for output formatters has been changed, so that it was necessary to upgrade our formatter for feature tests on continuous-integration systems.

Here is the code. For information on using it see Cucumber output formatter for continuous integration or the Cucumber wiki.

The code:imedo_ci_formatter.rb

Popularity: 1% [?]

Written by ehartung

April 28th, 2009 at 4:26 pm

Cucumber output formatter for continuous integration

without comments

After presenting a way of analyzing the features of a web application and determining the to-be value for feature tests (see model-driven feature testing) here is a little piece of code that may help you with the controlling of your feature tests.

We are using Cucumber to run our feature tests and in order to have up-to-date test results for our latest code we created a task in our continuous integration system which runs all feature tests once a day.

The only problem was that the output formatters included in Cucumber do not give much information about the results of the scenarios. But these are the numbers we are interested in since scenarios are the actual feature tests. Hence we wrote our own output formatter. It evaluates the executed scenarios and not the steps and it dismisses the fancy colors since it is meant to be used with a continuous integration sytem which only knows black and white.

To use our output formatter save it in features/support/ and run it by adding the format option to the Cucumber command line, e.g.:


CUCUMBER_OPTS="--format ImedoCiFormatter" cucumber features/

Below is the source code for our Cucumber output formatter. It first initializes arrays for error messages, passed scenarios, failed scenarios, and pending scenarios as well as flags to mark scenarios as failed or pending. When executing a feature the name of this feature is printed out. Afterwards all of its scenarios are executed. Therefore each scenario is checked whether it contains steps when it is started. If not, the scenario is marked as pending. If it does contain steps, they are executed.

In case one step failed the current scenario is marked as failed and the error message ist stored. If one step is pending the whole scenario is marked as pending, too.
At the end of each scenario the result is evaluated and printed out.

After all feature tests have been executed the pending scenarios, error messages, and stats of feature tests are dumped in a summary.

The code: imedo_ci_formatter.rb

Popularity: 1% [?]

Written by ehartung

April 16th, 2009 at 2:00 pm

CruiseControl.rb and changing SVN paths

without comments

When you move around some code in your SVN repository or like change the repository URL, CC.rb will start to complain because it isn’t able to find your code where it used to be. The message will be something like this:

svn: Cannot replace a directory from within

To fix this you can use

svn switch file:///this/is/the/path/to/my/new/svn/repo

But CC.rb will still complain and won’t build your project. In order to fix this, you have to commit once and CC.rb will pick up the changes and start building your project again.

We had this exact problem recently and it took some time to figure out how to solve it. So maybe this post will save someone some time.

Popularity: 1% [?]

Written by hvolkmer

August 28th, 2008 at 9:38 am