Product | Command Type |
---|---|
ClearCase | cleartool subcommand |
ClearCase LT | cleartool subcommand |
Attache | command |
Platform |
---|
UNIX |
Windows |
ClearCase, ClearCase LT, and Attache only-Create element trigger type:
ClearCase, ClearCase LT, and Attache only-Create type trigger type:
ClearCase and ClearCase LT only-Create a UCM trigger type:
A restriction-list for an element trigger type contains one or more of:
-att·ype attr-type-selector[,...] | -hlt·ype hlink-type-selector[,...] |
-brt·ype branch-type-selector[,...] | -lbt·ype label-type-selector[,...] |
-elt·ype elem-type-selector[,...] | -trt·ype trigger-type-selector[,...] |
An inclusion-list for a type trigger type contains one or more of:
-att·ype attr-type-selector[,...] | or | -att·ype -all |
-brt·ype branch-type-selector[,...] | or | -brt·ype -all |
-elt·ype elem-type-selector[,...] | or | -elt·ype -all |
-hlt·ype hlink-type-selector[,...] | or | -hlt·ype -all |
-lbt·ype label-type-selector[,...] | or | -lbt·ype -all |
-trt·ype trigger-type-selector[,...] | or | -trt·ype -all |
A restriction-list for a UCM trigger type contains one or more of:
-com·ponent component-selector[,...] (Default: All components) | |
-pro·ject project-selector[,...] (Default: All projects) | |
-str·eam stream-selector[,...] (Default: All streams) |
NOTE: -xxxtype aaa,bbb is equivalent to -xxxtype aaa -xxtype bbb.
The mktrtype command creates one or more trigger types for use within a VOB or UCM project VOB. A trigger type defines a sequence of one or more trigger actions to be performed when a specified ClearCase, ClearCase LT, or Attache operation occurs. The set of operations that initiates each trigger action-that is, causes the trigger to fire-can be very limited (for example, checkout only) or quite general (for example, any operation that modifies an element). You can use a restriction list to further limit the circumstances under which a trigger action is performed.
The trigger types are as follows:
An element trigger type works like a label type or attribute type: an instance of the type (that is, a trigger) must be explicitly attached to one or more individual elements with the mktrigger command. The trigger actions are performed when the specified operation is invoked on any of those elements. An element must exist before the trigger can be attached. (Putting a trigger on a mkelem operation has no effect.)
A variant of this type, called an all-element trigger type, is associated with the entire VOB. (Hence, no mktrigger command is required.) In effect, an instance of the type is implicitly attached to each element in the VOB, even those created after this command is executed. This trigger type is useful for disallowing creation of elements that have certain characteristics.
A type trigger type is associated with one or more type objects. The trigger actions are performed when any of those type objects is created or modified.
A UCM trigger type is attached to one or more UCM objects, such as a stream or activity, and fires when the specified operation is invoked on the UCM object. You can also create an all-UCM-object trigger type. Like the all-element type, this type is implicitly attached to all existing and potential UCM objects in the project VOB (that is, no mktrigger command is required).
Unlike other types, trigger types cannot be global.
Causing a set of trigger actions to be performed is called firing a trigger. Each trigger action can be either of the following:
Any command (or sequence of commands) that can be invoked from a shell or command prompt. A command can use special environment variables (EVs), described in the Trigger Environment Variables section, to retrieve information about the operation.
Any of several built-in actions defined by mktrtype. The built-in actions attach metadata annotations to the object involved in the operation.
Trigger actions execute under the identity of the process that caused the trigger to fire.
A script or batch file executed as (part of) a trigger action can interact with the user. The clearprompt utility is designed for use in such scripts; it can handle several kinds of user interactions through either the command line or GUI.
A single operation can cause any number of triggers to fire. The firing order of such simultaneous triggers is indeterminate. If multiple trigger operations must be executed in a particular order, use a single trigger that defines all operations in order of execution.
It is also possible for triggers to create a chain reaction. For example, a checkin operation fires a trigger that attaches an attribute to the checked-in version; the attach attribute operation, in turn, fires a trigger that sends mail or writes a comment to a file. You can use the CLEARCASE_PPID environment variable to help synchronize multiple firings (for more information, see Trigger Environment Variables).
If a trigger is defined to fire on a hyperlink operation, and the hyperlink connects two elements, the trigger fires twice-once for each end of the hyperlink.
The firing of a trigger can be suppressed when the associated operation is performed by certain identities. Firing of a trigger is suppressed if the trigger type has been made obsolete. (See the lock reference page).
The -execunix and -execwin options allow a single trigger type to have different paths for the same script, or completely different scripts, on UNIX and Windows hosts. When the trigger is fired on UNIX, the command specified with -execunix runs; when the trigger is fired on Windows, the command specified with -execwin runs.
Triggers with only -execunix commands always fail on Windows. Likewise, triggers that only have -execwin commands fail when they fire on UNIX.
The -exec option, whose command will run on both platforms, can be used in combination with the platform-specific options. For example, you can cascade options:
-exec arg1 -execunix arg2 -execwin arg3 -mklabel arg4 ...
A preoperation trigger (-preop option) fires before the corresponding operation begins. The one or more actions you've specified take place in their order on the command line.
This type of trigger is useful for enforcing policies:
If any trigger action returns a nonzero exit status, the operation is canceled.
If all trigger actions return a zero exit status, the operation proceeds.
For example, a preoperation trigger can prohibit checkin of an element that fails to pass a code-quality test.
A postoperation trigger (-postop option) fires after completion of the corresponding operation. The one or more actions you've specified take place in their order on the command line. This kind of trigger is useful for recording-in the VOB or UCM project VOB, or outside them-the occurrence of the operation. If a postoperation trigger action returns a nonzero exit status, a failed exit status
warning message is printed, but other trigger actions, if any, are executed.
For example, a postoperation trigger on checkin attaches an attribute to the checked-in version and sends a mail message to interested users and/or managers.
You can define an element trigger type or UCM trigger type (but not a type trigger type) with a restriction list. The restriction list limits the scope of the operation specified with -preop or -postop. The trigger fires only if the operation involves particular type objects.
A type trigger type is not associated with an element or UCM object, but with one or more type objects. When creating a type trigger type, you must specify an inclusion list, naming the type objects to be associated with the new trigger type. (Hence, it is unnecessary to use mktrigger to create the association.) The special keyword -all allows you to associate a type trigger type with every type object of a particular kind (for example, all branch type objects), even those objects created after you enter this command.
When a trigger fires, the trigger action executes in a special environment whose EVs make information available to -exec, -execunix, and -execwin routines: what operation caused the trigger to fire, what object was involved in the operation, and so on. The complete set of EVs is listed in TRIGGER OPERATIONS AND TRIGGER ENVIRONMENT VARIABLES.
Identities: For each object processed, you must be one of the following: type owner (applies to -replace only), VOB owner (element trigger types), project VOB owner (UCM trigger types) or:
UNIX: root
ClearCase on Windows: member of the ClearCase group
ClearCase LT on Windows: local administrator of the ClearCase LT server host
Locks: An error occurs if one or more of these objects are locked: the VOB (for an element trigger type), the project VOB (for a UCM trigger type), the trigger type (applies to -replace only).
Mastership: (Replicated VOBs only) No mastership restrictions.
See the permissions reference page.
SPECIFYING THE KIND OF TRIGGER TYPE. Default: None.
HANDLING OF NAME COLLISIONS. Default: An error occurs if a trigger type named type-name already exists in the VOB.
SPECIFYING THE OPERATIONS TO BE MONITORED. Default: None.
For both -preop and -postop, you must specify a comma-separated list of operations, any of which fire the trigger. Many of the operation keywords have the same names as cleartool subcommands (for example, checkout and unlock). Uppercase keywords (for example, MODIFY_ELEM) identify groups of operations. See the TRIGGER OPERATIONS AND TRIGGER ENVIRONMENT VARIABLES section for a list of operation keywords.
SUPPRESSING TRIGGER FIRING FOR CERTAIN USERS. Default: Triggers fire regardless of who performs the operation.
SPECIFYING THE TRIGGER ACTION. Default: None. Specify one or more of the following options to indicate the action to be performed when the trigger fires; you can use more than one option of the same kind. With multiple options, the trigger actions are performed in the specified sequence.
cleartool
prompt, enclose command-and any single quotes-in double quotes (" ' command ' "). (See also the cleartool reference page.)type-name | Name of the label type See the cleartool reference page for rules about composing names. | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
type-name | Name of the attribute type See the cleartool reference page for rules about composing names. | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
type-name | Name of the hyperlink type See the cleartool reference page for rules about composing names. | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
type-name | Name of the hyperlink type See the cleartool reference page for rules about composing names. | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
-mklabel RLS_2.3 | (literal) |
-mklabel RLS_$RLSNUM | (depends on value of EV at trigger firing time) |
-mklabel %THIS_RLS% | (depends on value of EV at trigger firing time) |
-mkattr ECO=437 | (literal) |
-mkattr ECO=$ECONUM | (depends on value of EV at trigger firing time) |
ELEMENT TRIGGER TYPES: SPECIFYING A RESTRICTION LIST. Default: No restrictions; triggers fire when any of the specified operations occurs, no matter what type objects are involved.
type-kind | One of | |
type-name | Name of the type object | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
-brtype rel2_bugfix | Fire the trigger only if the operation involves a branch of type rel2_bugfix. |
TYPE TRIGGER TYPES: SPECIFYING AN INCLUSION LIST. Default: None. You must specify at least one item for the inclusion list of a type trigger type.
-att·ype attr-type-selector[,...] | or | -att·ype -all |
-brt·ype branch-type-selector[,...] | or | -brt·ype -all |
-elt·ype elem-type-selector[,...] | or | -elt·ype -all |
-hlt·ype hlink-type-selector[,...] | or | -hlt·ype -all |
-lbt·ype label-type-selector[,...] | or | -lbt·ype -all |
-trt·ype trigger-type-selector[,...] | or | -trt·ype -all |
UCM TRIGGER TYPES: SPECIFYING A RESTRICTION LIST: Default: For -component, all components; for -project, all projects; for -stream, all streams.
EVENT RECORDS AND COMMENTS. Default: Creates one or more event records, with commenting controlled by your .clearcase_profile file (default: -cqe). See the comments reference page. Comments can be edited with chevent.
NAMING THE TRIGGER TYPE. Default: The trigger type is created in the VOB or UCM project VOB that contains the current working directory unless you use the @vob-selector suffix to specify another VOB.
type-name | Name of the trigger type See the cleartool reference page for rules about composing names. | |
vob-selector | VOB specifier Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB or project VOB is mounted) or of any file-system object within the VOB or project VOB (if the VOB is mounted) |
The following list shows the operation keywords (opkind) for use in definitions of type trigger types (mktrtype -type). In UNIX, the operation fires a trigger only if the affected object is a type object specified on the inclusion list, which is required.
NOTE: These operations are not ClearCase or ClearCase LT commands, although some have the same names as cleartool subcommands. These are lower-level operations, similar to function calls. See the events_ccase reference page for a list of which commands cause which operations.
chevent
chmaster
lock
mkattr
mkhlink
mktype (see NOTE)
modtype (see NOTE)
rmattr
rmhlink
rmtype
rntype
unlock
NOTE: If you specify mktype, the corresponding inclusion list cannot specify individual type objects; all relevant options must use the -all keyword. For example:
... -postop mktype -eltype -all -brtype -all ...
The modtype operation fires on the redefinition of attribute, branch, element, hyperlink, label, and trigger types.
Table 14 lists the operation keywords (opkind) for use in definitions of element and all-element trigger types (-element and -element -all). For any opkind, not all restrictions specified in the restriction-list argument are especially relevant; Table 14 also shows which restrictions are checked for each opkind. The opkinds in capitals (such as MODIFY_ELEM) specify all opkinds that appear under them; in other words, they are generalizations of the more specific opkinds.
See also the events_ccase reference page.
NOTE: These operations are not ClearCase or ClearCase LT commands, although some have the same names as cleartool subcommands. These are lower-level operations, similar to function calls. See the events_ccase reference page for a list of which commands cause which operations.
Operation keyword | Restrictions checked when trigger fires |
---|---|
MODIFY_ELEM | |
checkout | Element type, branch type |
chevent | See NOTE at end of table |
reserve | Element type, branch type |
uncheckout | Element type, branch type |
unreserve | Element type, branch type |
MODIFY_DATA | |
checkin | Element type, branch type |
chtype | All type objects |
lnname | Element type, branch type |
lock | See NOTE at end of table |
mkbranch | Element type, branch type |
mkelem | Element type |
mkslink | N/A |
protect | See NOTE at end of table |
rmbranch | Element type, branch type |
rmelem | Element type |
rmname | N/A |
rmver | Element type, branch type |
unlock | See NOTE at end of table |
MODIFY_MD | |
chmaster | See NOTE at end of table |
mkattr | Element type, attribute type, branch type |
mkhlink | Element type, hyperlink type, branch type |
mklabel | Element type, label type, branch type |
mktrigger | Element type, trigger type |
rmattr | Element type, attribute type, branch type |
rmhlink | Element type, hyperlink type, branch type |
rmlabel | Element type, label type |
rmtrigger | Element type, trigger type |
NOTE: The operation fires a trigger only if the affected object is one of the following:
A branch object or version object (in this case, only element type and branch type restrictions apply)
An element object (in this case, only element type restrictions apply)
A type object (in this case, only restrictions on that kind of type object apply)
Table 15 lists the operation keywords (opkind) for use in definitions of UCM object and all-UCM-object trigger types (-ucmobject and -ucmobject -all). The table shows the kind of UCM object to which the trigger may be attached-you may also use -all to specify all UCM objects. For any UCM operation, not all restrictions specified in the restriction-list argument are especially relevant; Table 15 also shows which restrictions are checked for each operation. You can use the UCM operation as a synonym for all other UCM operations; it causes a trigger to fire when any UCM operation for which triggers are enabled occurs.
NOTE: These operations are not ClearCase or ClearCase LT commands, although some have the same names as cleartool subcommands. These are lower-level operations, similar to function calls.
Operation keyword | Object type | Restrictions checked when trigger fires |
---|---|---|
UCM | ||
deliver_start | Target (integration) stream | Stream, Project |
deliver_cancel | Target (integration) stream | Stream, Project |
deliver_complete | Target (integration) stream | Stream, Project |
rebase_start | Target (development) stream | Stream, Project |
rebase_cancel | Target (development) stream | Stream, Project |
rebase_complete | Target (development) stream | Stream, Project |
mkactivity | Stream that is to contain the activity | Stream, Project |
chactivity | Activity being changed | Stream, Project |
rmactivity | Activity being removed | Stream, Project |
setactivity | Activity being set | Stream, Project |
mkstream | Project that is to contain the stream | Project |
chstream | Stream being changed | Stream, Project |
rmstream | Stream being removed | Stream, Project |
mkbl | Component that is to contain the baseline | Stream, Component, Project. No triggers are fired if the baseline is initial; if imported, triggers fire but the environment variables CLEARCASE_STREAM and CLEARCASE_PROJECT are undefined. |
chbl | Component that contains the baseline | Component, Project |
rmbl | Component that contains the baseline | Component, Project |
mkproject | The entire project VOB | None |
chproject | Project being changed | Project |
rmproject | Project being removed | Project |
mkcomp | The entire project VOB | None |
rmcomp | The entire project VOB | None |
mkfolder | Folder that is to contain the folder | Project |
chfolder | Folder that contains the folder | Project |
rmfolder | Folder that contains the folder | Project |
The following list shows the EVs that are set in the environment in which a trigger action script runs. The words in parentheses at the beginning of the description indicate which operations cause the EV to be set to a significant string; for all other operations, the EV is set to the null string. (See the events_ccase reference page for a list of which commands cause which operations.)
|
|
| |
---|---|
/vobs/proj/./releasedir |
(if VOB is mounted at '/vobs/proj') |
\proj1\.\releasedir |
(if VOB-tag is \proj1) |
| |
|
|
|
User Commands that Cause Multiple Operations | Operations | CLEARCASE_POP_KIND value |
---|---|---|
mkelem | mkelem | |
ln -s | mkslink | mkslink |
move | mv | lnname | rmname |
deliver_start | mkactivity | deliver_start |
rebase_start | mkactivity | rebase_start |
"Yes"
or 4657
).The UNIX examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.
The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.
In cleartool single-command mode, cmd-context represents the UNIX shell or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.
NOTE: Trigger environment variables are typically evaluated when the trigger fires, not when you enter the mktrtype command. If this is the case, escape the $ (UNIX) or % (Windows) environment variable symbol according to the conventions of the shell you are using. Escaping is not necessary if you enter the command manually in cleartool's interactive mode (that is, if it is not interpreted by a shell).
Create an element type named script for use with shell-script files. Then, create an all-element trigger type, chmod_a_plus_x, that makes newly created elements of type script executable. Convert a view-private file to an element of this type.
cmd-context mkeltype -supertype text_file -c "shell script" script
Created element type "script".
cmd-context mktrtype -element -all -postop mkelem -eltype script -nc \
-exec '/usr/atria/bin/cleartool protect -chmod a+x $CLEARCASE_PN' chmod_a_plus_x
Created trigger type "chmod_a_plus_x".
cmd-context mkelem -eltype script -ci -nc cleanup.sh
Created element "cleanup.sh" (type "script").
Changed protection on "/usr/hw/src/cleanup.sh".
Checked in "cleanup.sh" version "/main/1".
Create an all-element trigger type, to prevent files with certain extensions from being made into elements.
cmd-context mktrtype -element -all -nc -preop mkelem ^
-exec `\\photon\triggers\check_ext %CLEARCASE_PN%' check_ext
Created trigger type "check_ext".
Create an all-element trigger type, to run a script each time a checkin takes place.
cmd-context mktrtype -element -all -postop checkin -nc \
-exec /usr/local/bin/notify notify_admin
Created trigger type "notify_admin".
mail jones adm <<!
"notify_admin" Trigger:
checkin of "$CLEARCASE_PN"
version: $CLEARCASE_ID_STR
by: $CLEARCASE_USER
comment:
$CLEARCASE_COMMENT
!
Create an element trigger type that runs a script when a mkbranch command is executed. Specify different scripts for UNIX and Windows platforms.
cmd-context mktrtype -element -postop mkbranch -nc ^
-execunix /net/neon/scripts/branch_log.sh ^
-execwin \\photon\triggers\branch_log.bat branch_log
Created trigger type "branch_log".
Create an all-element trigger type to monitor checkins of elements of type c_source. Firing the trigger runs a test program on the file being checked in and may cancel the checkin.
cmd-context mktrtype -element -all -nc -preop checkin \
-exec '/net/neon/scripts/metrics_test $CLEARCASE_PN' \
-eltype c_source metrics_trigger
Created trigger type "metrics_trigger".
Create an all-element trigger type to attach a version label to each new version created on any element's main branch.
cmd-context mktrtype -element -all -postop checkin -mklabel REL\$BL_NUM \
-nc -brtype main label_i
Created trigger type "label_it".
Environment variable BL_NUM determines which version label is to be attached. This EV is evaluated at trigger firing time, because the dollar sign ($) is escaped.
Create a type trigger type to send a mail message each time any new branch type is created.
cmd-context mktrtype -type -nc -postop mktype -brtype -all \
-exec /net/neon/scripts/mail_admin new_branch_trigger
Created trigger type "new_branch_trigger".
Create a type trigger type to monitor the creation of new label types. The trigger aborts the label-type-creation operation if the specified name does not conform to standards.
cmd-context mktrtype -type -nc -preop mktype -lbtype -all
-exec '\\photon\triggers\check_label_name' ^
check_label_trigger
Created trigger type "check_label_trigger".
Create an element trigger type that, when attached to an element, fires whenever a new version of that element is checked in. Firing the trigger attaches attribute TestedBy to the version, assigning it the value of the CLEARCASE_USER environment variable as a double-quoted string.
NOTE: In this example, the single quotes preserve the double quotes on the string literal, and suppress environment variable substitution by the shell. The CLEARCASE_USER environment variable is evaluated at firing time.
cmd-context mktrtype -element -postop checkin \
-c "set attribute to record which user checked in this version" \
-mkattr 'TestedBy="$CLEARCASE_USER"' trig_who_didit
Created trigger type "trig_who_didit".
Create an all-element trigger type that prompts for the source of an algorithm when an element of type c_source is created. Firing the trigger executes a script named hlink_algorithm, which invokes the clearprompt utility to obtain the necessary information. The script then creates a text-only hyperlink between the newly created element object (for example, foo.c@@) and the specified text. The hlink_algorithm script is shown immediately after the mktrtype command.
cmd-context mktrtype -element -all -nc -postop mkelem -eltype c_source \
-exec /net/neon/scripts/hlink_algorithm describe_algorithm
Created trigger type "describe_algorithm".
clearprompt text -outfile /usr/tmp/alg.$CLEARCASE_PPID -multi_line \
-def "Internal Design" -prompt "Algorithm Source Document:"
TOTEXT=`cat /usr/tmp/alg.$CLEARCASE_PPID`
cleartool mkhlink -ttext "$TOTEXT" design_spec
$CLEARCASE_PN$CLEARCASE_XN_SFX
rm /usr/tmp/alg.$CLEARCASE_PPID
Use a postoperation trigger to modify the user-supplied comment whenever a new version is created of an element of type header-file
cmd-context mktrtype -element -all -nc -postop checkin -eltype header_file \
-exec '/usr/local/scripts/hdr_comment' change_header_file_comment
Created trigger type "change_header_file_comment".
hdr_comment script:
# analyze change to header file
CMNT=`/usr/local/bin/analyze_hdr_file $CLEARCASE_PN`
# append analysis to user-supplied checkin comment
cleartool chevent -append -c "$CMNT" $CLEARCASE_PN`
Create an all-element trigger type and a type trigger type that prevent all users except stephen, hugh, and emma from running the chmaster command on element-related objects and type objects in the current VOB:
cleartool mktrtype -element -all -preop chmaster -nusers stephen,hugh,emma ^
-execunix "Perl -e \"exit -1;\"" -execwin "ccperl -e \"exit (-1);\"" ^
-c "ACL for chmaster" elem_chmaster_ACL
cleartool mktrtype -type -preop chmaster -nusers stephen,hugh,emma ^
-execunix "Perl -e \"exit -1;\"" -execwin "ccperl -e \"exit (-1);\"" ^
-attype -all -brtype -all -eltype -all -lbtype -all -hltype -all ^
-c "ACL for chmaster" type_chmaster_ACL
Create a preoperation trigger type that fires on the deliver_start operation.
cmd-context mktrtype -ucmobject -all -preop deliver_start $PREOPCMDU $PREOPCMDW -stream $STREAM -nc $PREOPTRTYPE
Create a postoperationeration trigger type that fires on the deliver_complete operation.
cmd-context mktrtype -ucmobject -all -postop deliver_complete $WCMD $UCMD -stream $STREAM -nc $TRTYPE
events_ccase, lstype, mktrigger, rmtype
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |