Helix Core Trigger script type Reference Guide

Field

Meaning

name

The user-defined name of the trigger.

A run of the same trigger name on contiguous lines is treated as a single trigger, so that multiple paths may be specified. In this case, only the command of the first such trigger line is used.

type

Trigger types are divided into six subtypes: changelist submission triggers, shelve triggers, fix triggers, form triggers, authentication triggers, and archive triggers.

Changelist submission triggers:

•	change-submit: Execute a changelist trigger after changelist creation, but before file transfer. Trigger may not access file contents.

•	change-content: Execute a changelist trigger after changelist creation and file transfer, but before file commit.

To obtain file contents, use commands such as p4 diff2, p4 files, p4 fstat, and p4 print with the revision specifier @=change, where change is the changelist number of the pending changelist as passed to the script in the %changelist% variable.

•	change-commit: Execute a changelist trigger after changelist creation, file transfer, and changelist commit.

Shelve triggers:

•	shelve-submit: Execute a pre-shelve trigger after changelist has been created and files locked, but prior to file transfer.

•	shelve-commit: Execute a post-shelve trigger after files are shelved.

•	shelve-delete: Execute a shelve trigger prior to discarding shelved files.

Fix triggers:

The special variable %jobs% is available for expansion; it expands to one argument for every job listed on the p4 fix command line (or in the Jobs: field of a p4 change or p4 submit form), and must therefore be the last argument supplied to the trigger script.

•	fix-add: Execute fix trigger prior to adding a fix.

•	fix-delete: Execute fix trigger prior to deleting a fix.

Form triggers:

•	form-save: Execute a form trigger after the form contents are parsed, but before the contents are stored in the Perforce database. The trigger cannot modify the form specified in %formfile% variable.

•	form-out: Execute form trigger upon generation of form to end user. The trigger can modify the form.

•	form-in: Execute form trigger on edited form before contents are parsed and validated by the Perforce server. The trigger can modify the form.

•	form-delete: Execute form trigger after the form contents are parsed, but before the form is deleted from the Perforce database. The trigger cannot modify the form.

•	form-commit: Execute form trigger after the form has been committed for access to automatically-generated fields such as jobname, dates, etc.

For job forms, this trigger is run by p4 job as well as p4 fix (after the status is updated). The form-commit trigger has access to the new job name created by p4 job; any form-in and form-save triggers are run before the job name is created.

For job forms, this trigger is also run by p4 change (if a job is added or deleted by editing the Jobs: field of the changelist), and p4 submit (for any jobs present in the Jobs:field of the changelist). In these cases, the special variable %action% is available for expansion on the job form-commit trigger command line. The trigger cannot modify the form.

Authentication triggers:

•

auth-check: Execute an authentication check trigger to verify a user’s password against an external password manager during login, or when setting a new password If an auth-check trigger is present, the Perforce security configurable (and any associated password strength require­ment) is ignored, as authentication is now controlled by the trigger script.

•	auth-set: Execute an authentication set trigger to send a new password to an external password manager.

•	service-check: Execute a trigger to verify the password of a service user, rather than a standard user. Service check triggers work in the same way that auth-checktriggers do.

You must restart the Perforce server after adding an auth-check or service-check trigger.

Archive triggers:

•	archive: Execute the script when a user accesses any file with a filetype containing the +X filetype modifier.

The script is run once per file requested.

For read operations, scripts should deliver the file to the user on standard output. For write operations, scripts receive the file on standard input.

path

For changelist and shelve triggers (change-submit, change-content, change-commit, shelve-submit, shelve-commit, and shelve-delete), a file pattern in depot syntax. When a user submits a changelist that contains any files that match this file pattern, the script linked to this trigger is run. Use exclusionary mappings to prevent triggers from running on specified files.

For fix triggers (fix-add or fix-delete), use fix as the path value.

For form triggers (form-save, form-out, form-in, form-commit, or form-delete), the name of the type of form, (one of branch, change, client, depot, group, job, label, protect, spec, triggers, typemap, or user).

For authentication triggers (auth-check, auth-set, or service-check), use auth as the path value.

command

The command for the Perforce server to run when a matching path applies for the trigger type. Specify the command in a way that allows the Perforce server account to locate and run the command. The command must be quoted, and can take the variables specified below as arguments.

For change-submit and change-content triggers, changelist submission continues if the trigger script exits with 0, or fails if the script exits with a nonzero value. For change-commit triggers, changelist submission succeeds regardless of the trigger script’s exit code, but subsequent change-commit triggers do not fire if the script exits with a nonzero value.

For form-in, form-out, form-save, and form-delete triggers, the data in the specification becomes part of the Perforce database if the script exits with 0. Otherwise, the database is not updated.

The form-commit trigger type never rejects a change; it exists primarily so that scripts can access a job number (from the %formname% variable) during the process of job creation.

For fix-add and fix-delete triggers, fix addition or deletion continues if the trigger script exits with 0, or fails if the script exits with a nonzero value.

For auth-check and service-check triggers (fired by p4 login from standard users and service users respectively), the user’s typed password is supplied to the trigger command as standard input. If the trigger executes successfully, the Perforce ticket is issued. The user name is available as %user% to be passed on the command line.

For auth-set triggers, (fired by p4 passwd, but only after also passing an auth-check trigger check) the user’s old password and new password are passed to the trigger as standard input. The user name is available as %user% to be passed on the command line.