Main

July 13, 2006

Microsoft Software

  • Installed Microsoft Visual Studio.NET 2003
  • Installed Microsoft Installable File System
  • Installed MKS Toolkid
  • Changed script to resolve dependancies with new system
  • Updated env.pm to use cygpath

Continue reading "Microsoft Software" »

July 11, 2006

New Build Server

This entry will serve as documentation for making a new Windows build server for RIMF

  • New machine received with Windows 2003 XP (SP 1?) installed
  • Install Clearcase 2003.06.00
  • Installed Microsoft Visual Studio.NET 2003
  • Installed Cygwin
  • Installed JDK 1.4.2

Continue reading "New Build Server" »

July 7, 2006

Remove Empty Branch

  • Documented problems with empty branches

Continue reading "Remove Empty Branch" »

May 30, 2006

Osaka Builds on Windows

  • Worked with Zoran to resolve merge issues from RISS15_Integration -> osaka_strm
  • Documented how to build development views on Tiburon for the L2 and Base components
  • Assisted engineer on problems with view and installer_cmp
  • Changed RISS15_Integration to not do testing all the time
  • Worked more on osaka_strm build scripts

Continue reading "Osaka Builds on Windows" »

April 24, 2006

XAM Build

  • Got XAM ant build to work. Test build almost working
  • Ported Build.pl for use in XAM

Continue reading "XAM Build" »

April 17, 2006

Ant Rant

  • Studying Ant

Continue reading "Ant Rant" »

April 11, 2006

Build bugs, Test suite still not runing nightly

  • Fixed bug with saving test.log where I was attempting to save it before I returned from the subroutine. We now save the test.log even if test suite is successful. This is good because continuous building reuses the view area thus destroying any test.logs created before.
  • Fixed bug in build::CheckForShutdown where we called LogEvent without a $log parameter. This caused CheckForShutdown to abort the build while in CIT daemon mode and thus we didn't see the error. It also left the shutdown file thus subsequent starts merely shutdown (actually aborted) until one manually removed the shutdown file. Bad bug! Bad, bad!
  • Looking into why the test suite works when called at the Build.pl level but fails when called from the streamBuild.pl level.

April 10, 2006

Save the logfiles! IFrames

  • Changed the build process to save the test logfile
  • Changed the build_status to use an iframe for the continuous log file

March 30, 2006

Unit Test bugs

  • 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

Continue reading "Unit Test bugs" »

March 28, 2006

Remove Empty Branch Trigger

I have a trigger called the Remove Empty Branch Trigger:

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".

March 27, 2006

Resuming

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

February 23, 2006

CIT Building

Worked a lot on a script to drive the building. This script, called build, utilizes a configuration file as well as command line parameters to support adhoc kind of building (e.g. "Start a build but only build component X, noclean and do the testing, etc.).

Recently added what is called CIT (Continuous Intergration and Test) option as well as some build avoidance at the component level (utilizing the output from cleartool's update command). With --cit turned on the build script will attempt a build by first updating the view. It will then parse cleartool's update log. If nothing new came in for the component then the assumption is made that the component does not need to be rebuilt and skips it. After all components are built, streamBuild.pl will do other things like publishing and testing, etc. Next build will make a baseline (IFF the streamBuild.pl returns 0 status and at least one component was built) as well as update change logs on the web page.

When all of that is done, build will wait for 5 minutes and then restart itself.

Worked out a nasty bug where build was using chdir but streamBuild.pl was using $ENV {PWD}. Turns out that chdir does not change $ENV {PWD}. Fixed by doing "use Cwd qw(chdir)" which effectively sets $ENV {PWD} when chdir is called.

WARNING: Found out that streamBuild.pl was not that robust and does not return non zero status for some failures. For example, if it is not able to run unitTests it still might return a 0 status. This is bad. The streamBuild.pl script will have to be investigated and made to return good exit codes.

February 6, 2006

Back to HP

I'm back at HP, this time in Pleasanton working for the ILM doing Clearcase, Clearquest and release management. This division seems to rely heavily on an internal WIki for much of their documentation and process flow. Spent the first few says getting set up, installing my environment, getting logins, etc. Saw a requirement for an Evil Twin trigger so I offered up mine. Seems mine was not tested all that well under Unix and I had to change some things to remove the vob tag prefix. Also, handling of clearprompt on Unix is a little problematic. Seems that clearprompt is not gui oriented unless you specify -prefer-gui and even then it acts irratic because it does not pay attention to "\n" to represent new lines so I stuck with the non gui specification under Unix.