annotate
apropos
catcr
catcs
cc.icon
cc.magic
cd
chactivity
chbl
checkin
checkout
checkvob
chevent
chflevel
chfolder
chmaster
chpool
chproject
chstream
chtype
chview
clearaudit
clearbug
cleardescribe
cleardiffbl
cleardiff
clearexport_ccase
clearexport_cvs
clearexport_pvcs
clearexport_rcs
clearexport_sccs
clearexport_ssafe
clearfsimport
cleargetlog
clearhistory
clearimport
clearjoinproj
clearlicense
clearmake
clearmake.options
clearmrgman
clearprojexp
clearprompt
cleartool
clearviewupdate
clearvobadmin
comments
config_ccase
config_spec
cptype
credmap
creds
deliver
describe
diffbl
diffcr
diff
dospace
edcs
endview
env_ccase
events_ccase
export_mvfs
exports_ccase
file
find
findmerge
fmt_ccase
getcache
get
getlog
help
hostinfo
init_ccase
ln
lock
lsactivity
lsbl
lscheckout
lsclients
lscomp
lsdo
lsfolder
lshistory
ls
lslock
lsmaster
lspool
lsprivate
lsproject
lsregion
lsreplica
lssite
lsstgloc
lsstream
lstype
lsview
lsvob
lsvtree
makefile_aix
makefile_ccase
makefile_gnu
makefile_pmake
makefile_smake
makefile_sun
man
merge
mkactivity
mkattr
mkattype
mkbl
mkbranch
mkbrtype
mkcomp
mkdir
mkelem
mkeltype
mkfolder
mkhlink
mkhltype
mklabel
mklbtype
mkpool
mkproject
mkregion
mkstgloc
mkstream
mktag
mktrigger
mktrtype
mkview
mkvob
mount_ccase
mount
msdostext_mode
mvfslog
mvfsstorage
mvfstime
mvfsversion
mv
omake
pathnames_ccase
permissions
profile_ccase
promote_server
protect
protectvob
pwd
pwv
query_language
quit
rebase
recoverview
reformatview
reformatvob
register
relocate
rename
reqmaster
reserve
rgy_backup
rgy_check
rgy_passwd
rgy_switchover
rmactivity
rmattr
rmbl
rmbranch
rmcomp
rmdo
rmelem
rmfolder
rmhlink
rmlabel
rmmerge
rmname
rmpool
rmproject
rmregion
rmstgloc
rmstream
rmtag
rmtrigger
rmtype
rmver
rmview
rmvob
schedule
schemes
scrubber
setactivity
setcache
setcs
setplevel
setsite
setview
shell
snapshot.conf
softbench_ccase
space
startview
type_manager
umount
uncheckout
unlock
unregister
unreserve
update
version_selector
view_scrubber
vob_restore
vob_scrubber
vob_sidwalk
vob_snapshot
vob_snapshot_setup
wildcards_ccase
winkin
xclearcase
xcleardiff
xmldiffmrg
APPLICABILITY
Product | Command type |
---|---|
ClearCase | cleartool subcommand |
ClearCase LT | cleartool subcommand |
Platform |
---|
UNIX |
Windows |
SYNOPSIS
- Create element trigger type:
- mktrtype –ele·ment [ –a·ll ] [ –rep·lace ]
- { –pre·op | –pos·top } opkind[,...]
[ –nus·ers login-name[,...]
]
{ –exe·c command
| –execu·nix command
| –execw·in command
| –mkl·abel label-type-selector
| –mka·ttr attribute-type-selector=value
| –mkh·link hlink-type-selector, to=pname
| –mkh·link hlink-type-selector, from=pname } ...
[ restriction-list ]
[ –pri·nt ]
[ –c·omment comment | –cfi·le comment-file-pname | –cq·uery
| –cqe·ach | –nc·omment ] type-selector ...
- Create type trigger type:
- mktrtype –typ·e [ –rep·lace ] { –pre·op | –pos·top } opkind[,...]
- [ –nus·ers login-name[,...]
]
{ –exe·c command
| –execu·nix command
| –execw·in command
| –mkl·abel label-type-selector
| –mka·ttr attribute-type-selector=value
| –mkh·link hlink-type-selector,to=pname
| –mkh·link hlink-type-selector, from=pname } ...
inclusion-list [ –pri·nt ]
[ –c·omment comment | –cfi·le comment-file-pname | –cq·uery
| –cqe·ach| –nc·omment ] type-selector ...
- Create a UCM trigger type:
- mktrtype –ucm·object [ –a·ll ] [ –rep·lace ]
- { –pre·op | –pos·top } opkind[,...]
[ –nus·ers login-name[,...]
]
{ –exe·c command
| –execu·nix command
| –execw·in command
| –mka·ttr attribute-type-selector=value
| –mkh·link hlink-type-selector,to=pname
| –mkh·link hlink-type-selector,from=pname } ...
[ restriction-list ]
[ –pri·nt ]
[ –c·omment comment | –cfi·le comment-file-pname | –cq·uery
| –cqe·ach | –nc·omment ] type-selector ...
- 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:
–attype 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.
DESCRIPTION
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 or ClearCase LT 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.
TRIGGER FIRING
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.
Interactive Trigger Action Scripts
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.
Multiple Trigger Firings
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.
Suppressing Trigger Firing
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).
Trigger Interoperation
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 ...
PREOPERATION AND POSTOPERATION TRIGGERS
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.
RESTRICTION LISTS AND INCLUSION LISTS
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.
TRIGGER ENVIRONMENT VARIABLES
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.
RESTRICTIONS
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 administrators 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.
OPTIONS AND ARGUMENTS
Specifying the Kind of Trigger Type
- Default
- None.
- –ele·ment
- Creates an element trigger type, which can be attached to individual
elements with mktrigger.
- –ele·ment –a·ll
- Creates an all-element trigger type, which is implicitly attached to
all VOB objects, subject to the restriction list.
- –typ·e
- Creates a type trigger type and associates it with specific type objects
and/or kinds of type objects.
- –ucm·object
- Creates a UCM object trigger type, which can be attached to individual
UCM objects with mktrigger.
- –ucm·object –a·ll
- Creates an all-UCM-object trigger type, which is implicitly attached
to all project VOB objects, subject to the restriction list.
Handling of Name Collisions
- Default
- An error occurs if a trigger type named type-name already
exists in the VOB.
- –rep·lace
- Replaces the existing definition of type-name with
a new one. If you do not include options from the existing definition, their
values are replaced with the defaults.
If you specify a comment when using –replace, the comment appears in the event record for the modification (displayed with lshistory –minor); it does not replace the object's creation comment (displayed with describe). To change an object's creation comment, use chevent.
If an instance of an element or UCM trigger type is currently attached to any object, the replacement definition must correspond in kind: the new definition must be of an element trigger type or a UCM trigger type (but not an all-element or all-UCM object trigger type). You can remove an existing trigger type and all of its attached instances using the rmtype command.
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.
- –pre·op opkind[,...]
- Specifies one or more operations that cause the trigger to fire before
the operation starts. The exit status of the trigger actions is significant:
for each trigger action, a zero exit status allows the operation to proceed;
a nonzero exit status cancels the operation.
- –pos·top opkind[,...]
- Specifies one or more operations that cause the trigger to fire after
the operation completes. The exit status of the trigger action is not significant.
Suppressing Trigger Firing for Certain Users
- Default
- Triggers fire regardless of who performs the operation.
- –nus·ers login-name[,...]
- Suppresses trigger firing when any user on the comma-separated login-name list
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.
- –exe·c command
- Executes the specified command in a shell when the trigger fires. If command includes
one or more arguments, quote the entire string. Use single quotes ('command ')
if the command includes ClearCase or ClearCase LT environment variables,
to delay interpretation until trigger-firing time.
ClearCase and ClearCase LT on Windows—If you do not run mktrtype from the cleartool prompt, enclose command—and any single quotes—in double quotes (" ' command ' "). (See also the cleartool reference page.)
If you invoke a command built in to the Windows shell (for example, cd, del, dir, or copy), you must invoke the shell with cmd /c. For example:
–exec 'cmd /c copy %CLEARCASE_PN% %HOME%'
- –execu·nix command –execw·in command
- These options have the same behavior as –exec when
fired on the appropriate platform (UNIX or Windows, respectively). When fired
on the other platform, they do nothing; however, triggers with only –execunix commands
always fail on Windows, and triggers that only have –execwin commands
always fail on UNIX.
Note: On UNIX, If you use –execwin when defining a trigger type, you must escape backslashes in command with a backslash. Also, if you invoke a command built in to the Windows shell (for example, cd, del, dir, or copy), you must invoke the shell with cmd /c. For example:
–execwin 'cmd /c copy %CLEARCASE_PN% %HOME%'
- –mkl·abel label-type-selector
- (With –postop only) Attaches the specified version
label to the element version involved in the operation that caused trigger
firing. If the label type is a global type, a local copy of the type must
exist in the VOB in which you are creating the trigger type. Specify label-type-selector in
the form [lbtype:]type-name[@vob-selector].
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) - –mka·ttr attribute-type-selector=value
- (With –postop only) Attaches the specified attribute
name/value pair to the object involved in the operation that caused trigger
firing. If the attribute type is a global type, a local copy of the type must
exist in the VOB in which you are creating the trigger type. Specify attribute-type-selector in
the form [attype:]type-name[@vob-selector].
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) - –mkh·link hlink-type-selector,to=pname
- (With –postop only) Creates a hyperlink from
the object involved in the operation that caused the trigger to fire to the
object specified by pname. If the hyperlink type
is a global type, a local copy of the type must exist in the VOB in which
you are creating the trigger type. Specify hlink-type-selector in
the form [hltype:]type-name[@vob-selector].
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) - –mkh·link hlink-type-selector,from=pname
- (With –postop only) Creates a hyperlink from
the object specified by pname to the object involved
in the operation that caused the trigger to fire. If the hyperlink type is
a global type, a local copy of the type must exist in the VOB in which you
are creating the trigger type. Specify hlink-type-selector in
the form [hltype:]type-name[@vob-selector].
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) Note: With the built-in actions –mklabel, –mkattr, and –mkhlink, you can specify the information either literally or using environment variables:
–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 The built-in actions never cause additional triggers to fire. However, scripts or other programs invoked with –exec may cause such chain reactions. For example, a mklabel command in a shell script can cause another trigger to fire, but the corresponding –mklabel trigger action cannot.
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.
- –att·ype attr-type-selector[,...], –brt·ype branch-type-selector[,...], –elt·ype elem-type-selector [,...], –hlt·ype hlink-type-selector[,...], –lbt·ype label-type-selector[,...], –trt·ype trigger-type-selector[,...]
- Use one or more of the above options (or multiple options of the same
kind) to specify a set of type objects for the restriction list. If the type
object is an ordinary type, it must already exist. If a type object is a global
type and a local copy does not exist in the VOB, a local copy is created automatically.
Repeated options, such as –elt text_file –elt c_source, are equivalent to a single option: –elt text_file,c_source. Wildcarding ( –eltype ‘*file' ) is not supported.
At trigger-firing time, the items on the restriction list form a logical condition. If the condition is met, the trigger fires.
Specify the type-selector arguments in the form [type-kind:]type-name[@vob-selector]
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) |
Note: Suppressing the firing of a preoperation trigger allows the operation to proceed.
Here is a simple condition:
–brtype rel2_bugfix | Fire the trigger only if the operation involves a branch of type rel2_bugfix. |
If the list includes multiple type objects, they are combined into a compound condition: type objects of the same kind are grouped with logical OR; objects (or groups) of different kinds are then logically ANDed.
–brtype rel2_bugfix –eltype text_file,c_source | Fire the trigger only if the operation involves a branch of type rel2_bugfix AND it involves either an element of type text_file OR of an element of type c_source. |
In forming the condition, a type object is ignored if it could not possibly be affected by the operation. (The relevant information is included in the Trigger Operations and Trigger Environment Variables section.) For example, the restriction list –lbtype REL2,REL2.01 applies only to the operations chtype, mklabel, and rmlabel.
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
- You must specify at least one existing type object, or at least one
kind of type object, using the special keyword –all.
The trigger fires only if the inclusion list contains the type object that
is being modified or used by the operation.
UCM Trigger Types: Specifying a Restriction List
- Default
- For –component, all components; for –project,
all projects; for –stream, all streams.
- –com·ponent component-selector[,...] –pro·ject project-selector[,...]–str·eam stream-selector[,...]
- Use one or more of the above options to specify a set of UCM objects
for the restriction list. At trigger firing time, the items on the restriction
list form a logical condition: if the condition is met, the trigger fires.
component-selector is of the form [component:]component-name[@vob-selector], where vob-selector specifies the component's project VOB.
project-selector is of the form [project:]project-name[@vob-selector], where vob-selector specifies the project's project VOB.
stream-selector is of the form [stream:]stream-name[@vob-selector], where vob-selector specifies the stream's project VOB.
Tracing Trigger Execution
- Default
- At trigger firing time, if the environment variable CLEARCASE_TRACE_TRIGGERS is
set to a nonnull value for the process that causes the trigger to fire, a
message that includes the trigger type name is printed when the trigger fires;
a similar message is generated when the trigger action completes.
- –pri·nt
- Causes the messages to be generated at trigger firing time, whether
or not CLEARCASE_TRACE_TRIGGERS is set. –print writes
to stdout; on Windows systems therefore, you need
to define stdout for this option to be effective.
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.
- –c·omment comment | –cfi·le comment-file-pname |–cq·uery | –cqe·ach | –nc·omment
- Overrides the default with the option you specify. See the comments reference page.
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-selector ...
- One or more names for the trigger types to be created. Specify trigger-type-selector in
the form [trtype:]type-name[@vob-selector].
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)
TRIGGER OPERATIONS AND TRIGGER ENVIRONMENT VARIABLES
Trigger Operations for Type Trigger Types
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.
MODIFY_TYPE |
chevent |
chmaster |
lock |
mkattr |
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:
The modtype operation fires on the redefinition of attribute, branch, element, hyperlink, label, and trigger types.
Trigger Operations for Element and All-Element Trigger Types
Table 10 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 10also 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.
Table 10. Element Trigger Definition Operation Keywords
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)
Trigger Operations for UCM Objects and All-UCM-Object Trigger Types
Table 11 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 11 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.
Table 11. UCM Object Trigger Definition Operation Keywords
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. If imported, triggers fire but the environment variables CLEARCASE_STREAM and CLEARCASE_PROJECT are undefined. |
mkbl_complete | Stream where the baselines are to be created | Stream, Component, Project. Fires when all baselines that need to be created in the stream have been created. Does not apply to imported baselines |
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 |
setplevel (at 5.0) | The entire project VOB | None |
Trigger Environment Variables
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.)
- CLEARCASE_ACTIVITY
- (All deliver and rebase operations; checkin, checkout, mkactivity, chactivity, rmactivity, setactivity, uncheckout) The UCM activity, if applicable, involved in the operation that caused
the trigger to fire. For checkin, checkout,
and uncheckout operations, the activity that is set in
the view used for the operation. For the mkactivity, deliver_start,
and rebase_start operations, this environment variable
is set only for a postoperation trigger.
- CLEARCASE_ATTACH
- (mktrigger, rmtrigger) Set to 1 if
an element trigger type (except an all-element trigger type) is on the affected
element's attached list; set to 0 if it is on a directory
element's inheritance list. See the mktrigger reference
page for a description of these lists.
- CLEARCASE_ATTYPE
- (All operations that can be restricted by attribute type) Attribute
type involved in operation that caused the trigger to fire. In a rename operation,
the old name of the renamed attribute type object.
- CLEARCASE_BASELINES
- (All rebase operations, mkbl_complete, chbl, rmbl)
For the rebase operations, a space-separated list of all
UCM foundation baselines to which the destination stream is to be rebased.
For mkbl_complete, a list of all baselines created in the
stream; for the chbl and rmbl operations,
the list specifies only one baseline.
- CLEARCASE_BRTYPE
- (All operations that can be restricted by branch type) Branch type involved
in the operation that caused the trigger to fire. In a rename operation,
the old name of the renamed branch type object.
- CLEARCASE_CHGRP
- (protect) New group of the reprotected object as
specified in the command line; unset if not specified.
- CLEARCASE_CHMOD
- (protect) New protection of the reprotected object
as specified in the command line; unset if not specified.
- CLEARCASE_CHOWN
- (protect) New owner of the reprotected object as
specified in the command line; unset if not specified.
- CLEARCASE_CI_FPN
- (checkin) Pathname in checkin –from.
- CLEARCASE_CMDLINE
- (All operations initiated through use of the cleartool command) A string that specifies the cleartool subcommand and any options and arguments included on the command line.
- CLEARCASE_COMMENT
- (All operation kinds that support comments) Comment string for the command
that caused the trigger to fire.
- CLEARCASE_COMPONENT
- (mkbl, chbl, rmbl, mkcomp, rmcomp)
The UCM component containing the object involved in the action that caused
the trigger to fire, if applicable.
- CLEARCASE_COMPONENTS
- (mkbl_complete) A list of components associated with
the baselines created in the mkbl_complete operation.
- CLEARCASE_DLVR_ACTS
- (deliver_start, deliver_complete)
A space-separated list of all UCM activities merged during the deliver operation.
- CLEARCASE_ELTYPE
- (All operations that can be restricted by element type) Element type
of the element involved in the operation that caused the trigger to fire.
In a rename operation, the old name of the renamed element
type object.
- CLEARCASE_FOLDER
- (mkfolder, chfolder, rmfolder, mkproject, chproject, rmproject) The folder that contains the project.
- CLEARCASE_FREPLICA
- (chmaster) The old master replica, or from-replica:
the replica that mastered the object at the time the command was entered.
When the command chmaster –default brtype:branch-type-name is run at the site of the replica that masters the branch type, CLEARCASE_FREPLICA is set to the name of the current replica. If the command is run at a site that does not master the branch type, the command fails, but CLEARCASE_FREPLICA is set to the name of the replica that masters the branch type.
When the command chmaster –default branch-name is run, CLEARCASE_FREPLICA is set to the name of the current replica. (If the command is run at a site that does not master the branch, it fails.)
- CLEARCASE_FTEXT
- (mkhlink, rmhlink) Text associated
with hyperlink from-object.
- CLEARCASE_FTYPE
- (mkhlink, mkhlink on type) (“from”
type) Object selector of the type that the hyperlink being applied or removed
is from.
- CLEARCASE_FVOB_PN
- (mkhlink, rmhlink) Pathname of
VOB containing hyperlink from-object.
- CLEARCASE_FXPN
- (mkhlink, rmhlink) VOB-extended
pathname of hyperlink from-object.
- CLEARCASE_HLTYPE
- (All operations that can be restricted by hyperlink type) Hyperlink
type involved in operation that caused the trigger to fire. In a rename operation,
the old name of the renamed hyperlink type object.
- CLEARCASE_ID_STR
- (chactivity, checkin, checkout, mkattr, mkbranch, mkhlink, mklabel, rmattr, rmhlink, rmlabel, rmver) Version ID of version, or branch pathname of branch, involved
in the operation.
- CLEARCASE_IS_FROM
- (mkhlink, rmhlink) Set to 1 if CLEARCASE_PN contains name of hyperlink from-object;
set to 0 if CLEARCASE_PN contains
name of hyperlink to-object.
- CLEARCASE_LBTYPE
- (All operations that can be restricted by label type) Label type involved
in the operation that caused the trigger to fire. In a rename operation,
the old name of the renamed label type object.
- CLEARCASE_MODTYPE
- (mkattr, mkhlink, rmattr, rmhlink on
type) Object selector of the type for which the attribute or hyperlink is
being applied or removed.
- CLEARCASE_MTYPE
- (All) Kind (that is, the metatype) of the object involved in the operation
that caused the trigger to fire: element type, branch type, directory version,
and so on.
For mkattr, mkhlink, rmattr, rmhlink type triggers, CLEARCASE_MTYPE specifies the metatype of the type being modified, not the metatype of the attribute or hyperlink.
- CLEARCASE_NEW_TYPE
- (rename) New name of the renamed type object.
- CLEARCASE_OP_KIND
- (All) Actual operation that caused the trigger to fire.
- CLEARCASE_OUT_PN
- (checkout) Pathname in checkout –out.
(Same as CLEARCASE_PN if –out not
used.)
- CLEARCASE_PN
- (All operations; element triggers only) Name of element specified in
the command that caused the trigger to fire.
- With an all-element trigger, a pathname in the root directory of a VOB is reported with an extra (but still correct) "/." or “\.” pathname component:
- Some cleartool commands
rename files during their execution. Usually, such manipulations are unnoticeable,
but you may need to adjust your trigger scripts or batch files accordingly.
For example, the script for a preoperation mkelem trigger
may need to operate on file name “$CLEARCASE_PN.mkelem”
instead of “$CLEARCASE_PN” (UNIX)
or on name “%CLEARCASE_PN%.mkelem”
instead of “%CLEARCASE_PN%” (Windows)
- If the file does not exist
(for example, the checked-out file was removed), the value of CLEARCASE_PN is
different from its value when the file exists.
- CLEARCASE_PN2
- (lnname)
- CLEARCASE_POP_KIND
- (mkelem, mkslink, lnname, rmname, deliver, rebase) Parent operation kind. The mkelem and mkslink operations
both cause an lnname operation. If lnname happens
as a result of either of these parent operations, CLEARCASE_POP_KIND is
set to mkelem or mkslink, respectively.
Note that both the parent operations (mkelem and mkslink)
and the child operation (lnname) set CLEARCASE_POP_KIND to
the applicable parent operation value—mkelem or mkslink.
Commands that cause multiple operations Operations CLEARCASE_POP_KIND value mkelem mkelem lnname
mkelem mkelem
ln –s mkslink lnname
mkslink mkslink
move | mv lnname rmname
rmname lnname
deliver_start mkactivity setactivity
mkbl
deliver_start rebase_start mkactivity setactivity
mkbl
rebase_start The move or mv command is a special case because there is no move operation. Therefore, the CLEARCASE_POP_KIND environment variable is set to the values rmname and lnname to show that those operations were part of the command execution.
- CLEARCASE_PPID
- (All) Parent Process ID: the process ID of the ClearCase or ClearCase LT
program (for example, cleartool) that invoked
the trigger. This is useful for constructing unique names for temporary files
that will pass data between a preoperation trigger and a postoperation trigger,
or between successive parts of a multipart trigger action.
- CLEARCASE_PROJECT
- (All deliver, rebase and mkbl operations; mkactivity, chactivity, rmactivity, mkstream, chstream, rmstream, chbl, rmbl, mkproject, chproject, rmproject, setactivity)
The UCM project containing the object involved in the action that caused the
trigger to fire, if applicable. Not set for the mkbl operation
if this is an imported baseline.
- CLEARCASE_REPLACE
- (mkattr, mklabel) Set to 1 if
the user specified that the attribute or label instance is to be replaced;
otherwise, set to 0.
- CLEARCASE_RESERVED
- (checkin, checkout) Set to 1 if
the user requested a reserved checkout; set to 0 if
user requested an unreserved checkout.
- CLEARCASE_SLNKTXT
- (mkslink; that is, the ln –s command)
Text of the new VOB symbolic link.
- CLEARCASE_SNAPSHOT_PN
- (All operations executed in a snapshot view) The path to the root of
the snapshot view directory in which the operation that caused the trigger
to fire took place.
- CLEARCASE_SRC_STREAM
- (All deliver operations) The UCM stream from which
the deliver operation was initiated.
- CLEARCASE_STREAM
- (All deliver, rebase and mkbl operations; mkactivity, chactivity, rmactivity, setactivity, mkstream, chstream, rmstream, chbl, rmbl) The UCM stream containing the object
involved in the action that caused the trigger to fire, if applicable. For
the mkstream operation, a postoperation trigger only. Not
set for the mkbl, chbl, or rmbl operation
if this is an initial (or imported) baseline.
- CLEARCASE_TO_ACTIVITY
- (chactivity) The activity that will contain the versions
of elements. The activity that previously contained the versions is CLEARCASE_ACTIVITY.
- CLEARCASE_TO_FOLDER
- (chproject, chfolder) The folder that
will contain the project or folder.
- CLEARCASE_TREPLICA
- (chmaster) The new master replica, or to-replica: the
replica specified to receive mastership.
When the command chmaster –default brtype:branch-type-name is run at the site of the replica that masters the branch type, CLEARCASE_TREPLICA is set to the name of the current replica. If the command is run at a site that does not master the branch type, the command fails, but CLEARCASE_TREPLICA is set to the name of the current replica.
When the command chmaster –default branch-name is run, CLEARCASE_TREPLICA is set to the name of the replica that masters the branch type. (If the command is run at a site that does not master the branch, it fails.)
- CLEARCASE_TRTYPE
- (All operations that can be restricted by trigger type) Trigger type
involved in the operation that caused the trigger to fire. In a rename operation,
the old name of the renamed trigger type object.
- CLEARCASE_TRTYPE_KIND
- (All operations that can be restricted by trigger type) Kind of trigger
type; setting this variable to pre-operation or post-operation causes
the trigger to fire before or after the trigger operation, respectively.
- CLEARCASE_TTEXT
- (mkhlink, rmhlink) Text associated
with hyperlink to-object.
- CLEARCASE_TYPE
- (mkhlink, mkhlink on type) Object
selector of the type which the hyperlink being applied or removed is to.
- CLEARCASE_TVOB_PN
- (mkhlink, rmhlink) Pathname of
VOB containing hyperlink to-object.
- CLEARCASE_TXPN
- (mkhlink, rmhlink) VOB-extended
pathname of hyperlink to-object.
- CLEARCASE_USER
- (All) The user who issued the command that caused the trigger to fire;
derived from the UNIX real user ID or the Windows user ID.
- CLEARCASE_VAL
- (mkattr) String representation of attribute value
for CLEARCASE_ATTYPE (for example, "Yes" or 4657).
- CLEARCASE_VIEW_KIND
- (All operations) The kind of view in which the operation that caused
the trigger to fire took place; the value may be dynamic, snapshot,
or snapshot web.
- CLEARCASE_VIEW_TAG
- (All non-UCM operations; for UCM, all deliver and rebase operations
and setactivity) View tag of the view in which the operation
that caused the trigger to fire took place.
- CLEARCASE_VOB_PN
- (All) VOB tag of the VOB or UCM project VOB whose object was involved
in the operation that caused the trigger to fire.
A combination of the CLEARCASE_VOB_PN and CLEARCASE_PN environment variables can be used to extract the VOB-only pathname. Because the CLEARCASE_VOB_PN variable contains the VOB tag, it can be used to determine where the VOB part of a pathname begins in CLEARCASE_PN.
- CLEARCASE_VTYPE
- (mkattr) Value type of the attribute in CLEARCASE_ATTYPE (for
example, string or integer).
- CLEARCASE_XN_SFX
- (All) Extended naming symbol (such as @@) for host on which the operation
took place.
- CLEARCASE_XPN
- (All operations; element triggers only) Same as CLEARCASE_ID_STR,
but prepended with CLEARCASE_PN and CLEARCASE_XN_SFX values,
to form a complete VOB-extended pathname of the object involved in the operation.
EXAMPLES
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.
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 '/opt/rational/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 /opt/rational/bin/notify notify_admin
Created trigger type "notify_admin".notify script:
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".hlink_algorithm script:
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 postoperation trigger type that fires on the deliver_complete operation.
cmd-context mktrtype -ucmobject -all -postop deliver_complete $WCMD $UCMD
-stream $STREAM -nc $TRTYPE