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

-i

Read the trigger table from standard input without invoking the editor.

-o

Write the trigger table to standard output without invoking the editor.

g-opts

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

super

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.

Related Commands

To obtain information about the changelist being submitted

p4 describe
p4 opened

To aid daemon creation

p4 review
p4 reviews
p4 counter
p4 counters
p4 user