There is a bug in the YAML implementation in Ruby 1.8.1 which makes DamageControl crash a couple of times every day. Usually something like the following is displayed in the log and in the console output:
Installing Ruby 1.8.2 solves the problem (it is currently in preview2 but should be released soon).
DC has absolutely no knowledge of what the build command it executes actually does. It just launches the command you tell it to launch. (Could be notepad.exe or gimp for that matter - try it!). Since the build command is an arbitrary command, there might not even be any (system err/system out) output from it, so DC doesn't try to parse that output. (Although it pipes it to a log file which you can browse to from the web admin).
What DC does is quite old fashioned (yet a well-established paradigm, at least in unix land): It looks at the return code from the build command. If it's 0 it is OK, otherwise it is KO. In short this means that your build command (whatever it is) must make sure to return a non-0 return code in the event of a build failure. Ant, Maven and Make do that.
If you are writing a your build script in shell-script or some other scripting languages like Python and Ruby you need to make sure you are exiting with a non-zero exit code on build failure. Have a look at ant.bat to see how to do it from a .bat script.
For example, the DamageControl build scripts (written in ruby and which of course are built in DamageControl itself) have code that looks something like this:
Under UNIX, the exit status of a shell script is the same as the last command run, which is generally what you want.
Under Windows, you may have to add
exit %errorlevel% to the end of your batch file.
In your build command line cd to that directory and then execute the command line you need to build. Your build command line could look something like this:
Say you have a project named
myproject and you want to for example perform the deployment phase in a different build stage than the initial one. There is currently no explicit support for this in DamageControl but it's relatively easy to accomplish anyway using a trick:
- Create a new project named
myproject-deployto be a child build of
myproject(so it gets triggered at each commit).
myproject-deployso it has no SCM and that the build command line looks something like: Where
/var/damagecontrol/project/checkout/projectis the full path to the checkout directory of the parent project
deployis the actual command to execute the
DamageControl has the ability (see DC-240) to have builds 'pinned' to certain executors. This means that each build can control which executors will, or won't, be allowed to execute it.
Why would I want to pin a build?
Well there's a number of ways this would be useful, but for example in our scenario we have 8 or 9 functional test builds that must be run in serial (ie FTest A, FTest B, FTest C etc). The advantage to having multiple executors allows us to reduce the average time for each build. However if the problem is that if we have a set of serial builds like this we can no longer have multiple executors because we can't guarantee they won't start to parallel each other. Pinning all these builds to a single executor means that they will run in serial, but won't block the entire build queue.
So how do I pin a build?
It's not documented anywhere (hence why I'm writing this FAQ) but it really is quite simple.
To pin a build, you need to edit it's conf.yaml file (usually located in DCHOME/work/projectname) and add the following line:
(this will pin the current build to only the "FunctionalTests" build executor)
The executor_selector property is a regex that must match the executor name. The default value is \.* - hence the default is to match all executors.
Why can't I pin a build through the web UI?
This feature hasn't been implemented yet, but it is scheduled (DC-241).
Sometimes you get an error like this:
This is because the REXML distributed with certain versions of Ruby is pretty crappy. So DamageControl includes its own REXML version but in order to have the included version override the version distributed with Ruby you need to specify the switch "-I<damagecontrol home>/server" (or "-I." if you are in that directory) when starting the test-suite or the server.
So instead of:
This could be because you have specified a relative path in the library path ('.' for example, as in
ruby -I. script.rb) and have changed the working directory somewhere in the script. There are basically one workaround and one solution to this problem, the workaround is simply to specify an absolute path instead of the relative path. The solution is to use the
with_working_dir method (in the
FileUtils module) instead of changing the directory with
with_working_dir restores the previous working directory before it exits. Like this: