p4 triggers
Synopsis
Create or display a list of scripts to be run conditionally whenever changelists are submitted, forms are updated, when integrating Perforce with external authentication or archive mechanisms, when rotating journals, or when pushing or fetching content to and from a remote depot.
Syntax
p4 [g-opts
] triggers
p4 [g-opts
] triggers
-o
p4 [g-opts
] triggers
-i
Description
Perforce triggers are user-written scripts or programs that are called
by a Perforce server whenever certain operations (such as changelist
submission or changes to forms) are performed. If the script returns a
value of 0
, the operation continues; if the script returns any other
value, the operation fails.
The p4 triggers
command includes three variants:
- With no options specified, the command invokes the default editor to allow the user to specify one or more trigger definitions.
- The
-i
option specifies that the user use standard input to specify one or more trigger definitions. - The
-o
option displays the trigger definitions currently stored in the trigger table.
A trigger definition contains four fields that specify the name of the trigger, the type of event that should trigger the execution of the script, the location of the script, and other trigger type-dependent information. When the condition specified in a trigger definition is satisfied, the associated script or program is executed.
For detailed information about writing triggers and trigger definitions, see "Scripting Perforce: Triggers and Daemons" in the Helix Versioning Engine Administrator Guide: Fundamentals.
Options
|
Read the trigger table from standard input without invoking the editor. |
|
Write the trigger table to standard output without invoking the editor. |
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
N/A |
N/A |
|
Examples
Suppose that the trigger table consists of the following entries:
Triggers: trig1 change-submit //depot/dir/... "/usr/bin/s1.pl %changelist%" trig2 change-submit //depot/dir/file "/usr/bin/s2.pl %user%" trig1 change-submit -//depot/dir/z* "/usr/bin/s1.pl %user%" trig1 change-submit //depot/dir/zed "/usr/bin/s3.pl %client%"
Note the indentation; the Triggers:
field name is not indented; each
row is indented with at least one space or tab character.
Both the first and third lines call the script /bin/s1.pl
%changelist%
, because the first occurrence of a particular trigger name
determines which script is run when the trigger name is subsequently
used.
No triggers are activated if someone submits file //depot/dir/zebra
,
because the third line excludes this file. If someone submits
//depot/dir/zed
, the trig1
script /usr/bin/s1.pl
%changelist%
is run: although the fourth line overrides the third,
only the first script associated with the name trig1
is called.
For more detailed examples, see "Using triggers to customize behavior" in Helix Versioning Engine Administrator Guide: Fundamentals.