I am in the process of converting our existing custom continuous build system to use TeamCity. Our current system is brittle and requires a degree of maintenance we can ill afford. TeamCity appears to work well for many of our build scenarios. One scenario leaves me wondering if there is a better way to utilize TeamCity.
We have a hardware project that is set up to build using Eclipse configured with a specific set of tool chains. Developers run the IDE, and for lack of an Eclipse build runner, I am using TeamCity to build the project from a commandline runner using python scripts.
The script runs launches Eclipse from the command line numerous times to performing the following tasks:
- Delete the contents of the Eclipse workspace.
- Import a number (10 or so) of Eclipse projects into the workspace.
- Build the workspace
The problems with this approach are as follows:
- There is no build runner for Eclipse. The scripts work, but there is overhead in developing and maintaining the scripts. This is the very thing we are trying to get away from.
- There is no TeamCity parsing of the output (gcc and eclipse). I have to redirect the output to file, and when each individual Eclipse process finishes, parse the file for errors, warnings, progress status, etc., in order to inject the appropriate TeamCity service message to stdout. Again this kind of overhead is the very thing we are trying to get away from.
Given no Eclipse build runner just days away from release, is there a better mechanism for loading and building an Eclipse workspace with TeamCity?
Given the commandline runner script solution, is there a better machnism for capturing and displaying errors, warnings, etc.?