Triggers and commit-edge

This section explains how you manage existing Triggers in a commit-edge configuration and how you use edge type triggers.

Determining the location of triggers

In a distributed Perforce service, triggers might run either on the commit server, or on the edge server, or perhaps on both.

Make sure that all relevant trigger scripts and programs are deployed appropriately. Edge servers can affect non-edge type triggers in the following ways:

If you enforce policy with triggers, you should evaluate whether a change list or shelve trigger should execute on the commit server or on the edge server.
Edge servers are responsible for running form triggers on workspaces and some types of labels.

Trigger scripts can determine whether they are running on a commit or edge server using the trigger variables described in the following table. When a trigger is executed on the commit server, %peerip% matches %clientip%.

Trigger Variable	Description
`%peerip%`	The IP address of the proxy, broker, replica, or edge server.
`%clientip%`	The IP address of the machine whose user invoked the command, regardless of whether connected through a proxy, broker, replica, or edge server.
`%submitserverid%`	For a `change-submit`, `change-content`, or `change-commit` trigger in a distributed installation, the `server.id` of the edge server where the submit was run. See `p4 serverid` in the Helix Core Command-Line (P4) Reference for details.

Using edge triggers

In addition, edge servers support two trigger types that are specific to edge-commit architecture: edge-submit and edge-content:

Trigger Type	Description
`edge-submit`	Executes a pre-submit trigger on the edge server after changelist has been created, but prior to file transfer from the client to the edge server. The files are not necessarily locked at this point.
`edge-content`	Executes a mid-submit trigger on the edge server after file transfer from the client to the edge server, but prior to file transfer from the edge server to the commit server. At this point, the changelist is shelved.

Triggers on the edge server are executed one after another when invoked via p4 submit -e. For p4 submit, edge-submit triggers run immediately before the changelist is shelved, and edge-content triggers run immediately after the changelist is shelved.

Because edge-submit triggers run prior to file transfer to the edge server, these triggers cannot access file content.

The following edge-submit trigger is an MS-DOS batch file that rejects a changelist if the submitter has not had the change reviewed and approved. This trigger fires only on changelist submission attempts that affect at least one file in the //depot/qa branch.

@echo off
rem REMINDERS
rem - If necessary, set Perforce environment vars or use config file
rem - Set PATH or use full paths (C:\PROGRA~1\Perforce\p4.exe)
rem - Use short pathnames for paths with spaces, or quotes
rem - For troubleshooting, log output to file, for instance:
rem - C:\PROGRA~1\Perforce\p4 info >> trigger.log
if not x%1==x goto doit
echo Usage is %0[change#]
:doit
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul
if errorlevel 1 echo Your code has not been reviewed for changelist %1
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul

To use the trigger, add the following line to your triggers table:

sampleEdge   edge-submit //depot/qa/...   "reviewcheck.bat %changelist%"