p4 triggers

Synopsis

Edit a list of scripts to be run conditionally whenever changelists are submitted.

Syntax

Description

A pre-submit trigger is a user-written script that Perforce has been told to run whenever particular files are submitted in a changelist. If the script returns a value of 0, the submit continues; if it returns any other value, the submit fails.

Triggers are run in the order listed in the table; if one trigger script fails, subsequent trigger scripts are not run. Even when a trigger script succeeds, the submit may fail because of subsequent triggers, or for other reasons. Thus, pre-submit triggers should be used only for validation, and should not perform operations that are dependent on the successful completion of the submit. If this is necessary, create a daemon instead.

To use the same trigger script with multiple file patterns, list the same trigger multiple times in the trigger table. Exclusionary mappings can be provided to exclude files from activating the trigger script; in this case, the order of the trigger entries matters, just as it does when exclusionary mappings are used in views (see the Examples section, below).

If a particular trigger name is listed multiple times, only the script corresponding to the first use of the trigger name is activated.

Form Fields

The p4 triggers form contains a single field, called Triggers. Each row in the table has three values; these values are:

Options

Usage Notes

• Arguments may be passed to the trigger script. The variables are specified in the trigger table as follows:

  Argument	Description
  %changelist%	The number of the changelist being submitted
  %client%	Name of the client workspace that submitted the changelist
  %clienthost%	Hostname of the client
  %clientip%	The IP address of the client
  %serverhost%	Hostname of the Perforce server
  %serverip%	The IP address of the server
  %serverport%	The IP address and port of the Perforce server, in the format ip_address:port
  %serverroot%	The value of the server's P4ROOT; the top-level directory of the server's files and metadata
  %user%	The Perforce username of the user who submitted the changelist

• If your trigger script needs to know which files were submitted in the changelist, use p4 opened -ac changelist#.
• The trigger script can't access the submitted file contents from the server, since the files have not yet been stored there. But if the server has access to the client machine, the file contents can be obtained from the client via OS commands.
• Perforce commands in trigger scripts are always run by a specific Perforce user. If this is not properly planned for, an extra Perforce license for a user named SYSTEM might be consumed. Some of the other options are:

  · Use the %user% argument to the script within each Perforce command so that the script is run by the submitting user. For example, if Joe has submitted a changelist that activates trigger script foo.pl, and this script runs the p4 changes command, the script can run the command
  p4 -u %user% changes.

  · Set P4USER for the account that runs the trigger script to the name of an existing user. (Windows NT services can't have P4USER values; for Windows NT services, you should always use the script's %user% value).

Examples

Suppose that the trigger table consists of the following entries:

trig1 //depot/bar/... "/usr/bin/s1.pl %changelist%"

trig2 //depot/bar/foo "/usr/bin/s2.pl %user%"

trig1 -//depot/bar/z* "/usr/bin/s1.pl %user%"

trig1 //depot/bar/zed "/usr/bin/s3.pl %client%"

Both the first and fourth lines call the script /bin/s1.pl %changelist%, since the first occurrence of a particular trigger name determines which script is run when that trigger name is subsequently used.

No triggers are activated if the user submits file //depot/bar/zebra, since the third line excludes this file. But if //depot/bar/zed is submitted, the trig1 script /usr/bin/s1.pl %change% will be run, since the fourth line overrides the third, and because the first script listed with the name trig1 is used.

Related Commands