Status for Andrew DeFaria

• I think I finally resolved the problem with the Unit Tests not running at night
• Changed to get the test failures and the test errors. If everything passed then no email is to be sent. Otherwise I now include the test failures and errors in the email and the subject line will no longer say SUCCEEDED
• Changed build_status.php to sense if this is a continuous build or just a regular build and act accordingly

Unit Tests

It was a problem to debug because we have a sitaution here where build is calling streamBuild.pl which is in turn calling Build.pl with -runtests. Additionally streamBuild.pl was using a library called buildRec.pm who had a functon called unitTests. Now recently I added code to fork before exec'ing "perl Build.pl -runtests" so that I could set an alarm and time out test suites that hang. I have not yet mastered debugging forked processes in Perl.

Additionally, build was not just calling streamBuild.pl in a Perl sense, rather it was exec'ing streamBuild.pl as it's a Perl script in its own right. So I was attempting to debug just the exeuction of streamBuild.pl from the command line. But whenever I did that the tests would work. Still the nightly testing would fail on trying to call "perl Build.pl -runtests" stating that it could not find Build.pl!

It seems to turn out that there was a clash between my using the Cwd module (which more accurately tracks changing of directories) while streamBuild.pl was not using that module. Additionally it (or rather buildRec.pm which streamBuild.pl uses) was reffering to $ENV {PWD} and that was returning inaccurate information. For example, it was saying that we were in the directory /build when we had just did a chdir to /build/views/<view>/vobs/platform/L3 - were there is indeed a Build.pl! However the script got the wrong current directory and then based things off that, including the finding of Build.pl. I changed this to use `pwd` and now it appears happy!

Posted by at 5:54 PM | Permalink

Remove Empty Branch Trigger: This trigger removes the branch and the zero element that is left when a user checks out an element on a branch then cancels the checkout. Normally this causes a branch with only a zero element which is identical to the version from which it was branched. Essentially this empty branch is useless. This trigger prevents that.

Not only is this empty branch useless but:

• It clutters the version tree
• Causes Clearcase to maintain more meta data, slowing down operations
• Can cause additional work for UCM when you rebase

I'm experiencing that last bullet item right now. At one time I was attempting to do a delivery for somebody from another stream, first rebasing my stream. The delivery was unsuccessful and it was decided that this other engineer would work on it and deliver himself. So I canceled the delivery. One would think then that my view was relatively clean.

However now I want to deliver something else and I see this old rebase activity hanging around. In looking into the change set I notice a bunch of items from that older attempt at delivering. Why were these still hanging around? I had canceled that delivery right?

Well I believe the problem comes from having empty branches. Take for example the following:

It shows a rebase from osaka/5 -> defaria_osaka/1. Yet these two version compare to be the same! How did this happen? Well think about it. Prior to the rebase I had an empty branch (i.e. I had defaria_osaka/0 left over from the canceled delivery which merely did an unco). This means that osaka/4 and defaria_osaka/0 were identical. Then osaka/5 came into existance. Now 4 != 5 and when I rebase Clearcase has to propogate osaka/5 creating defaria_osaka/1. Now I have two identical versions and associate meta data and all for naught! Additionally I have a baseline lable on defaria_osaka/1 which give the air of importance to this unimportant version.

Had we had a remove empty branch trigger, when the delivery canceled, the unco would have left defaria_osaka/0 and the remove empty branch trigger would have removed the empty branch. Then my view would have been pointing to osaka/4 (and would have moved to osaka/5 if I were using .../osaka/LATEST and a dynamic view or updated to osaka/5 during the normal course of updating the view). Indeed, allowing empty branches to persist can cause developers to unknowingly get "stuck in time".

Posted by at 2:25 PM | Permalink

I haven't been keeping this up lately but I've decided to resume my status even if I don't use this as my actual status report.

First I'll try to catch up by summarizing what I've been working on lately. Mostly I've been working on this CIT (Continuous Integration and Test) Perl script. CIT is basically an controlling script that calls other build scripts in use here. The idea was to have this script continually build the software, if it needs to build. A primative form of build avoidance is implemented in that a cleartool update is done and if no files are updated in a particular component then that component will not be built.

Some of its characteristics include:

• Can run in one time mode as well as in -cit mode (continuous mode)
• Works off of a config, which specifics defaults for the various parameters which can be overriden on the command line
• If -cit is specified, the script goes into daemon mode.
• Script checks to see if you are in the necessary chrooted environment for building (a requirement)
• Added code in cit mode to eliminate the logfiles created if nothing was built
• At key points in a build a build_status.log file is updated so status can be displayed on a web page
• After a successful build a series of tests are run. Continuous build is not too continuous if the testing hangs! And tests have been known to hang! So the script now forks the tests then sets an overall alarm (default 2 hours) for tests to complete. If they don't then a QUIT signal is sent so that the JREs can try to dump their stacks. After a small wait for that a TERM signal is send to all children fo the tests and again we wait. Finally a KILL signal is sent and an appropriate email is then sent out saying that the tests have timed out
• Corresponding PHP script was written to show the status of the cit

Posted by at 5:42 PM | Permalink