5 most important ClearCase Triggers

Question

Policy #1: All changes to sources should be recorded and comments should be provided.

% mktrtype -element -global -preop checkin \
       -exec comment_policy.sh CommentPolicy
Trigger action script: 
#!/bin/sh
#
#      comment_policy
#
ACCEPT=0
REJECT=1
WORDCOUNT=`echo $CLEARCASE_COMMENT | wc -w`
if [ $WORDCOUNT -ge 10 ] ; then
      exit $ACCEPT
else
      exit $REJECT
fi

Policy #2: The system must track the progress of each source file through the official approval stages.

% mktrtype -element -global -preop checkin \
       -exec check_status.sh CheckStatus
Trigger action script:
#!/bin/sh
#
#      check_status
#
ACCEPT=0
REJECT=1
ATTYPE="Status"
if [ "`cleartool find $CLEARCASE_XPN \
       -version 'attype($ATTYPE)' -print`" ]
then
       exit $REJECT
else
       exit $ACCEPT
fi

Policy #3: All the versions that went into the building of Release 2 — and only those versions — should be labeled REL2.

What are the appropriate versions? If Release 2 was built “from the bottom up” in a particular view, you can label the versions selected by that view:

% cleartool mklabel -recurse REL2 top-level-directory 

To prevent version label REL2 from being used further, lock the label type:

% cleartool lock -lbtype REL2 
       ... and then: 
% cleartool lock -nusers vobadm -lbtype REL2

The -nusers option provides a controlled “escape hatch” — the object will be locked to all users, except the specified ones.

Policy #4 Whenever anyone changes the GUI, mail should be sent to the Doc Group, for a documentation update.

Post-operation triggers are designed to support such notification-oriented policies. First, create a trigger type that sends mail, then attach it to the relevant elements.

Trigger definition:

% cleartool mktrtype -nc -element -postop checkin \ 
        -exec informwriters.sh InformWriters 
Created trigger type "InformWriters".

Place the trigger on the inheritance list of all existing directory elements within the GUI source tree:

% cleartool find /vobs/gui_src -type d \ 
       -exec 'mktrigger -recurse -nattach InformWriters 
 $CLEARCASE_PN'

Place the trigger on the attached list of all existing file elements within the GUI source tree:

Trigger action script:

#!/bin/sh
#
#   check_status
#
DOC_GROUP="john george"
mail $DOC_GROUP << 'ENDMAIL'
New version of element created: $CLEARCASE_PN
                            by: $CLEARCASE_USER
Comment string:
---------------
$CLEARCASE_COMMENT
ENDMAIL

Policy #5 “Fixes to a past release must be performed in isolation, starting with the exact configuration of versions that went into that release.”

This policy fits perfectly with ClearCase's baselevel-plus-changes development model. First, a REL2 label must be attached to the release configuration, as described in the preceding scenario. Then, a view configured with the following config spec implements the policy:

element * CHECKEDOUT
element * .../rel2_bugfix/LATEST
element * REL2 -mkbranch rel2_bugfix

If all fixes are performed in one or views with this configuration, all the changes will be isolated on branches of type rel2_bugfix. The -mkbranch clause causes such branches to be created automatically, as needed, when element are checked out.

This config spec selects versions from rel2_bugfix branches, where branches of this type exist; it creates such a branch whenever a REL2 version would be checked out