8.1 Overview of Triggers

A trigger is a monitor that causes one or more procedures or actions to be executed whenever a certain ClearCase operation is performed. Typically, the trigger executes a Perl, batch, or shell script. You can use triggers to restrict operations to specific users and to specify the conditions under which they can perform those operations. You can use triggers with the following UCM operations:

• chbl

• chfolder

• chproject

• chstream

• deliver

• mkactivity

• mkbl

• mkcomp

• mkfolder

• mkproject

• mkstream

• rebase

• rmbl

• rmcomp

• rmfolder

• rmproject

• rmstream

• setactivity

• setplevel

Preoperation and Postoperation Triggers

Triggers fall into one of two categories. Preoperation triggers fire, or execute their corresponding procedures, before an operation takes place. Postoperation triggers fire after an operation occurs. Use preoperation triggers to prevent users from performing operations unless certain conditions apply. Use postoperation triggers to perform actions after an operation completes. For example, you may want to place a postoperation trigger on the deliver operation to notify team members whenever a developer delivers work to the project's integration stream. Figure 36 illustrates the timing of preoperation and postoperation triggers.

Figure 36 Preoperation and Postoperation Triggers

Scope of Triggers

A trigger type defines a trigger for use within a VOB or PVOB. When you create a trigger type, with the cleartool mktrtype command, you specify the scope to be one of the following:

• An element trigger type applies to one or more elements. You attach an instance of the trigger type to one or more elements by using the cleartool mktrigger command.

• An all-element trigger type applies to all elements in a VOB.

• A type trigger type applies to type objects, such as attributes types, in a VOB.

• A UCM trigger type applies to a UCM object, such as a stream or a project, in a PVOB.

• An all-UCM-object trigger type applies to all UCM objects in a PVOB.

Using Attributes with Triggers

As you design triggers to enforce development policies, you may find it useful to use attributes. An attribute is a name/value pair. An attribute type defines an attribute. You can apply an attribute to an object, such as a stream or an activity, or to a version of an element. In your trigger scripts, you can test the value of an attribute to determine whether to fire the trigger. For example, you could define an attribute type called TESTED and attach a TESTED attribute to elements to indicate whether they had been tested. Acceptable values would be Yes and No.

When to Use ClearQuest Scripts Instead of UCM Triggers

This chapter presents several use cases for UCM triggers. If your UCM project is enabled to work with Rational ClearQuest, you can set the following policies, which are described in UCM-ClearQuest Integration:

• Check Before Work On

• Check Before ClearCase Delivery

• Do ClearQuest Action After Delivery

• Check Mastership Before Delivery

Each of these policies has a ClearQuest global hook script associated with it, which you can edit or replace in ClearQuest Designer to customize the policy for your environment. You can also write your own ClearQuest hooks to enforce development policies. In general, if the policy you want to enforce involves a ClearQuest action, use one of the ClearQuest policies listed above or use ClearQuest hooks. If the policy you want to enforce involves a ClearCase action, use UCM triggers.