Luntbuild is a powerful build automation and management tool. Continuous Integration or nightly builds can be easily set using a clean web interface. Executed builds are well managed using functions such as search, categorization, promotion, patching, deletion, etc. It also acts as a central build artifacts repository and download area for your whole team.
Why Luntbuild?
You may ask why Luntbuild, while there are already many good build automation tools such as Cruise Control, Anthill, and others. Our answer is:
- Luntbuild aims at not only being build automation, but also build management system. Executed builds can be categorized, promoted, searched, patched, deleted, etc. This is very important for a nightly builds or Continuous Integration builds, which generate many builds over time.
- Luntbuild utilizes the project/schedule concept to easily provide build support for parallel development.
- No configuration files, all jobs are done using web interface. You can set your Luntbuild system in less than thirty minutes.
Features
Supports following
Version Control Systems:
- Accurev
- Cvs
- Visual Sourcesafe
- Subversion
- StarTeam
- Perforce
- Base Clearcase
- Clearcase UCM
- File system
Following
databases may be used to store Luntbuild data:
- HSQLDB embedded (in process)
- H2 embedded (in process)
- H2 client/server
- MySql
- ProgreSql
- SqlServer
- Oracle
- Derby client/server
Supports following
build tools:
- Ant
- Maven
- Maven2
- Shell script
- Rake
Luntbuild uses the concepts of a project, Version Control System (VCS) adaptor, and schedule to automate and manage builds. The project is a "real world" project, and corresponds to a set of particular source repositories. The VCS adaptor is a group of versioned directories or files, usually defined by a path into the VCS repository with a particular branch or label.
In Luntbuild, schedules are not only used to implement non-interactive builds, but schedules are also used to implement build categorization. For example, you can configure your project with three schedules, hourly, nightly, and release. The hourly and nightly schedules will be triggered automatically, and the release build schedule is only triggered manually. The hourly schedule can be configured to build incrementally in order to increase the build speed (only code changed since last build is checked out), and the do not label option can be chosen in order not to introduce too many labels into the repository. The hourly schedule mainly serves as the continuous integration build, to ensure the integrity of the source repository. The nightly schedule can be configured as a clean (from scratch) build in order to increase the reliability of the build, and the label when successful option can be chosen in order to make all nightly builds reproducible. The nightly schedule will be used as the development environment update, which can be used to create the base development environment. The release build schedule is used to produce a build to be released to public. You can use the pre-build categorization method by manually triggering the release build using the release schedule, or you can use the post-build categorization method by moving a particular build (for example a tested build in the nightly category) to the release category.
In addition to build categorization and promotion, builds can also be searched by build version with non-exact or exact matches, by "from date" and "to date", by status, or by build schedules. Build deletion can be performed on search results, or on a specific build. For example, you could perform operations such as "search all failed history builds" and delete them. Also, for a particular build, existing artifact files can be deleted, and new files can be uploaded, for example, to supply patches for a particular build.
RSS feed Java Forums
