Triggering before or after commands

Triggers of type command allow you to configure Helix Server to run a trigger before or after a given command executes. You might want to execute a script.

Before a command runs After a command runs

Before a command runs	After a command runs
prevent a user with the `admin` protection from running p4 obliterate so that only a user with `super` protections can make a file unrecoverable prevent a user from running p4 sync against the commit server because using an edge server might improve performance (see Example command trigger below) prevent the user from runing any command that is not specifically included in a list of allowed commands Tip Sometimes a new release of the server adds a new command. It is safer to decide whether to explicitly add the new command to an 'allowed' list rather than using a 'disallowed' list that permits all new commands by default.	connect its action with that of another tool or process, such as: connecting the creation of a new stream with an email notification to the admin adding to a spreadsheet the list of non-admin users who run p4 users, p4 clients, and p4 streams because gathering such information by non-admins might be considered suspicious

prevent a user with the admin protection from running p4 obliterate so that only a user with super protections can make a file unrecoverable
prevent a user from running p4 sync against the commit server because using an edge server might improve performance (see Example command trigger below)
prevent the user from runing any command that is not specifically included in a list of allowed commands

Tip
Sometimes a new release of the server adds a new command. It is safer to decide whether to explicitly add the new command to an 'allowed' list rather than using a 'disallowed' list that permits all new commands by default.

connect its action with that of another tool or process, such as:

connecting the creation of a new stream with an email notification to the admin
adding to a spreadsheet the list of non-admin users who run p4 users, p4 clients, and p4 streams because gathering such information by non-admins might be considered suspicious

Note

If you are Using Helix Core Server for Distributed Versioning, consider Triggering on pushes and fetches.

The following table describes the fields of the command trigger.

Field	Meaning
`name`	The name of the command trigger.
`type`	`command` The command to execute is specified in the `path` field.
`path`	The `pre-user-command` value specifies the command before which the trigger should execute. The `post-user-command` value specifies the command after which the trigger should execute. `command` can be a regular expression. For the grammar of regular expressions, see p4 help grep. Examples of possible values: pre-user-login post-user-add post-user-edit pre-user-obliterate pre-user-sync - see Example command trigger below post-user-sync To match a command name that is a substring of another valid command, use the end-of-line meta-character to terminate matching. For example, use `change$` so you don’t also match `changes`. You cannot create a `pre-user-info` trigger. See also Additional triggers for push and fetch commands.
`command`	The trigger for Helix Server to run when the condition implied by `path` is satisfied. Specify the command in a way that allows Helix Server to locate and run the command. The `command` (typically a call to a script) must be quoted, and can take as arguments anything that your `command` is capable of parsing, including any applicable Helix Server trigger variable. When your trigger script is stored in the depot, its path must be specified in depot syntax, delimited by percent characters. For example, if your script is stored in the depot as `//depot/scripts/myScript.pl`, the corresponding value for the command field might be `"/usr/bin/perl %//depot/scripts/myScript.pl%"`. See Storing triggers in the depot for more information.

Example command trigger

You might want a pre-user-sync trigger to run before a user's request to sync (p4 sync) is executed.

An example of a trigger table entry, check-sync command pre-user-sync "check-sync.pl %serverservices%", is shown below in a comment:

#!/usr/bin/perl
# Example pre-user-sync command trigger
# Trigger table entry:
# check-sync command pre-user-sync "check-sync.pl %serverservices%"

$serverservices = $ARGV[0]; # from %serverservices% in trigger table
$allowed_to_sync_from = 'edge-server';
if ($serverservices eq $allowed_to_sync_from) {
    exit 0;
    } else {
    print 'Sync must only be run from edge servers !';
    exit 1;
}