Browse Prior Art Database

A method to automatically identify the check-in that has caused the build/test failure

IP.com Disclosure Number: IPCOM000200897D
Publication Date: 2010-Oct-29
Document File: 1 page(s) / 45K

Publishing Venue

The IP.com Prior Art Database

Abstract

When a developer checks-in a piece of code that does not compile, it breaks the daily build stalling the whole development and testing of the product. Proposed method identifies the check-in that has caused the build failure and alert the developer whose code changes are responsible for the break in the build.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 78% of the total text.

Page 01 of 1

A method to automatically identify the check -in that has caused the build/test failure

When working on a major release of a product, it is usual practice to have daily builds of the code. This daily build is needed by the testers to test the bug fixes, by the developers to share fixes and code. When a developer checks-in a piece of code that does not compile, it breaks the daily build.

Such an event stalls the whole development and testing of the product and causes losses to an organization.

Problem: Break in the build, has to be quickly and efficiently identified and the developer whose code changes are responsible for the event should be alerted as soon as possible.

In order to avoid the cost incurred by the break in the build, we propose a solution that would quickly and efficiently identify the check-in that has caused the build failure and alert the developer whose code changes are responsible for the break in the build. All this would be done automatically as part of the daily build process itself. Please note that same concept can be extended to test failures also (in scenarios where regression tests are run daily/periodically).

Described is a method to automatically identify the check-in that has caused the build/test failure, and sending an alert to the owner of that particular check-in.

The implementation of the proposed solution would be achieved in following steps:

1. In event of a build failure, assume that there are 'n' check-ins.
2. Revert back al...