Status for Andrew DeFaria

• Worked on implementing tail
• Worked with Sujay a bit on the ASAP_BUS_REQ trigger. Need to get a testign environment

Posted by at 6:22 PM | Permalink

• Attended a few meetings which took up my time
• Worked about 2 1/2 hours on rmelem'ing some files for BUCS
• Added installation of TUP to install script for CCADMIN. Need to propogate this to the other install scripts. Involved adding stuff to HKLM RunOnce for TUP install

Posted by at 5:28 PM | Permalink

• Worked a little on the problem with Core_automation and diff
• Installed Ant and JDK into CM_TOOLS and performed a build of ASAP_Infrastructure!
• Performed code review of INHIBIT_DUPLICATE_ELE

Posted by at 6:19 PM | Permalink

• Wrote LogActivity trigger which will log activity to an HTML log file. It requires one parameter, the path to where to put the log file. Thereafter it writes log files of the format _yyyy-mm-dd.html.
• Added LogActivity trigger to ASAP_Docs and ASAP_BUS_REQ vobs
• Changed old ASAP_NOTIFY trigger to use the generic NotifyTrigger.pl script with a message file for ASAP and another one with a different message file for ASAP_BUS_REQ
• Adjusted triggers.dat to reflect this
• Modified etc/*.reg file to include Clearquest settings in an ASCII form

Posted by at 5:17 PM | Permalink

• Created new tools view named PMO
• Installed ASAP_NOTIFY trigger
• Created installation scripts

PMO View

The vobadm_tools_view recently had a problem. Originally it was created by Brian as a snapshot view and a dynamic view - not a recommended practice I'm sure. Anyways, I was not able to update it recently. It complained about CM_TOOLS not being a Clearcase object! I banged on it for a while and couldn't figured it out. Sensing an opportunity to shorten a pathname, I discussed this with Don and we decided to create a new snapshot view, on the real view server (rtnlprod02) with a shorter name. So I created the PMO snapshot view. This makes the path \\rtnlprod02\viewstore\PMO\CM_TOOLS\...

Note, I have already taken care of adjusting the triggers, mktriggers.pl, ccase_[un]lock_vobs.bat jobs and the task_registry.

ASAP_NOTIFY Trigger

Triggers are kept in the CM_TOOLS vob. Also there is a mktriggers.pl script whose responsibility is to add/replace all triggers to all vobs. It works off a data file and is a fairly flexible facility. Some triggers are applied to all vobs (e.g. PROTECT), some to base Clearcase vobs only (e.g. CHECK_COMMENT) and some to specific vobs (e.g. ASAP_NOTIFY). This script is designed to be run at any time and will reinstate the correct status of triggers in the vobs. It is very handy to have a script to set up your triggers. One place where this will be very useful is when we get to Multisiting things. Multisite will replicate the vobs but not their triggers. Multisite can be used to make a "backup region" which can be useful in disaster recovery. Being able to quickly reinstate your triggers in these cases if very valuable.

As for another trigger to log activity I see it going this way...

A vob activity trigger is a useful idea and it's conceivable that other projects might want such a facility. Being that the "log" is really an html file there are only 2 things that are needed: 1) a web server and it's URL and 2) writable space to put these html files. Additionally one might be concerned with managing this space (trimming/removing log files over time) and perhaps presenting an interface into this history.

I think a trigger should be developed or culled out of the current trigger, which performs two distinct tasks, generalized and made available for the ASAP_Docs vob and other vobs as the vob owners require. This trigger can be implemented as an "all element" trigger (covering the whole vob) or just a trigger that can be attached as we have done for 03_Design. Being generalized more information must be written into the log (html) file to distinguish the elements more precisely. These are the vob name (e.g. ASAP_Src) and the path into the vob (e.g. ASAP\Include) (If we keep on logfile per vob then the vob name can stay promoted in the heading).

So the table entry would change from:

Elements modified in \ASAP_Docs on 05-17-2004

To:

This would not be that hard. The trigger would take one parameter, the path to the share to write the html files to (e.g. \\webapp01\Rational\asapcm\logs in the instant case).

If this trigger was created and implemented (and removed from the current trigger) then all that's left in the current trigger is the sending of email. This could be accomplished with the existing NotifyTrigger.pl and a data file such as:

From: Vobadm 
To: <***ADD EMAIL ADDRESSES HERE***>
Subject: $CLEARCASE_OP_KIND notification: $CLEARCASE_PN
--
This is a notification that a $CLEARCASE_OP_KIND has occurred:

Element:        $CLEARCASE_PN
Branch:         $CLEARCASE_BRTYPE
Operation:      $CLEARCASE_OP_KIND
User:           $CLEARCASE_USER
View:           $CLEARCASE_VIEW_TAG
Comments:

$CLEARCASE_COMMENT

The trigger replaces $ENVIRONMENT_VARIABLE. We would just need to modify this data file to be From: ASAPAdmin@Ameriquest.net (and we really should hook up a real person to that email address), add the email addresses to the To line.

The URL http://ASAPCM.Ameriquest.net/logs is a directory so the web server will look for certain files such as index.html and index.cgi. An index.cgi script could be written that writes out a web page showing today's activity, complete with a little calendar with links to prior history.

Actually, I'd recommend perhaps collapsing the modified/newelements by adding a column that simply says something like "Modified" or "Added". This way we don't have to deal separately with modified vs. newly added in index.cgi nor in any of the historical html logfile.

This way the email message is simplified. The recipients get notification via email that something has changed with enough information to tell them the specific change. If they want to know about other things that changed recently they are pointed to one place to see the current data, with an easy way to scroll back through time.

Now I've done such little web apps on my domain (http://defaria.com) in Perl and PHP. Given a preference I'd prefer PHP. However http;//asapcm.ameriquest.net is running IIS and I have no idea of how to set up and run Perl/PHP on IIS.

Posted by at 4:45 PM | Permalink