Trigger definition
After you have written a trigger, you create the trigger definition by issuing the p4 triggers
The 'p4 triggers' form in which each trigger is defined by four fields. Sometimes referred to as the 'triggers table'.. You must be a Helix Core Server superuser to run this command.
Field names (such as Triggers:) must be flush left (not indented) and must end with a colon. Field values (that is, the set of lines you add, one for each trigger) must be indented with spaces or tabs on the lines beneath the field name.
Example trigger definition for a single trigger
The p4 triggers form looks like this:
Triggers: relnotecheck change-submit //depot/bld/... "/usr/bin/rcheck.pl %user%" verify_jobs change-submit //depot/... "/usr/bin/job.py %change%"
In this example:
-
relnotecheckis thename -
change-submitis thetype -
//depot/bld/...is thepath, which, depending on the type of trigger, might take a value that looks different from this example -
"/usr/bin/rcheck.pl %user%"is thecommand, where%user%is a trigger variable passed to the Perl script. See Trigger script variables.
Trigger fields
This triggers form has three trigger definitions, and each trigger definition has four fields.
Triggers: relnotecheck change-submit //depot/bld/... "/usr/bin/rcheck.pl %user%" verify_jobs change-submit //depot/... "/usr/bin/job.py %change%" check-sync command pre-user-sync "check-sync.pl %serverservices%"
| Trigger Definition Fields | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Field | Meaning | |||||||||||||||||||
|
|
The user-defined name of the trigger. To use the same trigger script with multiple file patterns, list
the same trigger multiple times on contiguous lines in the
trigger table. Use exclusionary mappings to prevent files from
activating the trigger script. The order of the trigger entries
matters, just as it does when exclusionary mappings are used in
views. In this case, only the |
|||||||||||||||||||
|
|
Each type of trigger corresponds to an event that causes that type of trigger to fire.
|
|||||||||||||||||||
|
|
The meaning of this field depends on the trigger type. For example:
To learn what this field means for a trigger type that you want to use, see the section about that trigger type. |
|||||||||||||||||||
|
|
Specify the trigger in a way that allows Helix Core Server to locate and run the command when the conditions of the trigger definition are satisfied. The Specify the name of the trigger script or executable in ASCII, even when the server is running in Unicode mode and passes arguments to the trigger script in UTF8. The On those platforms where the operating system does not know how
to run the trigger, specify an interpreter in
the command field. For example, Windows does not know how to run
lo form-out label "perl //myscripts/validate.pl" Two more command examples:
If your trigger script is stored in the depot, its path must
be specified in depot syntax, delimited by percent characters.
For example, if your script is stored in the depot as
|
|||||||||||||||||||
How triggers run
Triggers are run in the order listed in the triggers form. If a trigger fails for a specified type, subsequent trigger also associated with that type do not run.
The p4 triggers command has this
syntax:
p4 triggers [ -i | -o ]
- With no flags, the user’s editor is invoked to specify the trigger definitions.
- The
-iflag reads the trigger table from standard input. - The
-oflag displays all the trigger definitions stored in the trigger table.
