Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# 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 P4 CLI 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%"

Your search for returned results