[SCM] source code management-perforce trigger and daemon

Perforce provides 2 middleware to allow users to customize or enhance the features of perforce: trigger and daemon.

 

One triggers
Triggers is a user-defined script, but it is automatically called by p4server under certain conditions to execute certain functions. If the script returns 0, it indicates the execution is successful. If the script returns a non-0 value, it indicates that the script fails to be executed, and the output of the script is returned as an error message as a client.

Common trigger functions: integrates LDAP or ad user authentication methods, locks branch, standardizes the changelist description during submission, and describes new bugs or task management systems.

1) trigger table
P4server uses the trigger table to manage all the triggers. You can run the P4 trigger command to view all the triggers. For example:
Triggers:
Relnotecheck change-submit // depot/bld/... "/usr/bin/rcheck. pl % USER %"
Verify_jobs change-submit // depot/... "/usr/bin/job. py % change %"

The trigger table consists of multiple rows. Each row represents the information of a trigger. Each trigger contains multiple columns, indicating:
Name: The name of a trigger. Generally, the trigger name contains the role information;
Type: trigger type, which can be divided into the following six types: changelist submission triggers, shelve triggers, fix triggers, form triggers, authentication triggers, and archive triggers.
Path: the path of the branch to which the trigger acts. This parameter is required for changlist and shelve trigger;
Command: the command to be executed when the trigger meets the conditions. The command needs to be included and some P4 custom variables can be used in the command, for example; % change % = % changelist %, % SERVERPORT %, % USER %, etc.

2) trigger type

Changelist submission triggers:
* Change-Submit: After changelist is created, trigger is executed before file transfer;
* Change-content: After changlist is created, trigger is executed when file transfer is completed but changelist is not submitted;
* Change-commit: After changlist is created, trigger is executed after the file is transferred and changlist is submitted;

Shelve triggers:
* Shelve-Submit: equivalent to pre-shelve trigger. After changelist is created and the file is locked, trigger is executed before file transfer;
* Shelve-commit: equivalent to post-shelve trigger. Trigger is executed after the file is shelved;
* Shelve-delete: run the trigger before dropping the sheleved file;

Fix triggers:
* Fix-add: execute trigger before adding a fix;
* Fix-delete: execute trigger before deleting a fix;

Form triggers:
* Form-save: trigger is executed when the form content is parsed but not stored in p4server dB;
* Form-out: After the form is generated, the trigger can be executed to modify the form;
* Form-in: trigger is executed before the content is parsed and verified when the form is modified. You can modify the form;
* Form-delete: After the content is parsed before the form is deleted, trigger is executed. You can modify the form;
* Form-commit: After the form is submitted, the trigger cannot be modified;

Authentication triggers:
* Auth-check: performs the authentication check trigger to verify the user's password based on the external password management system. When this trigger is set, the P4 Security Counter related to the new user's password settings is ignored.
* Auth-set: This trigger is used to send a new password to an external password management system.

3) custom variables that can be used in command
% Action %: null or string is used to reflect operations on changelist or job, such as "submitted Change 124 deleted ";
% Changelist % change %: Indicates changelist. Change-submit trigger imports the pending changelist. Change-commit trigger transfers the submitted changelist;
% Changeroot %: root path of the submitted file;
% Client %: the user's client name;
% Clienthost %: host information set by the user client;
% Clientip %: IP address of the client;
% Jobs %: job numbers;
% Oldchangelist %: If the changelist changes after submission, % oldchangelist % indicates the old changelist before submission;
% Serverhost %: The name of p4server;
% Serverip %: the IP address of p4server;
% SERVERPORT %: indicates the port of p4server;
% Serverroot %: the root directory of p4server;
% USER %: indicates the user of the current operation;
% Formfile %: indicates the temporary form spec file in form-related operations;
% Formname %: form name, for example, changelist or branch name;
% Formtype %: Form type, such as branch and change;
% OP %: indicates read, write, or delete in the archive operation;
% File %: Path of the file in the archive operation;
% Rev %: version of the file in the archive operation;

4) trigger execution sequence
If there are multiple triggers, the execution order is

Change-submit-> change-content-> change-commit
Form-out-> form-in-> form-save-> form-delete

 

 

Two daemon
Daemon is a user-defined script and is executed at a specified time by the user. It is generally used to detect changes to the p4server and then perform some operations. For example, a P4 review daemon script checks the latest changes on the p4server every few minutes, and then sends a mail Code Modify persons of interest.

1) Common daemon:

P4 Change Review daemon, which is executed every ten minutes to check whether a new chagnelist is submitted. If a new chagnelist exists, the daemon checks whether the user has subscribed to the files contained in the changelist. the user who subscribes to the daemon sends an email to notify the user of the modification of the related files.

P4 job daemon is used to generate open job reports every day and send them to interested personnel.

P4 web daemon is used to automatically sync the latest modifications of some depots on p4server to a directory, which is set to Web shared and can be viewed by users through a web browser.

 

2) P4 Change review is set to run every 10 minutes in task schedule or Linux daemon. The execution process is as follows:
* P4 counter named Review records the end of the last review as chagnelist;
* P4 review-T review is used to obtain all new changelist information from the last review until now;
* For each changelist, use P4 review-C changelist # To obtain the subscriber of the files contained in this changelist;
* Then, send an email to all these users. The email content will be P4 describe changelist #;
* Use the command P4 changes-M 1-s submitted to obtain the latest chagnelist. Set the latest changelist to the rereview counter value P4 counter review [latestchangelist #].

 

Complete!