Perforce Public Knowledge Base - Triggers in a Distributed Perforce Environment
Perforce Software logo
Reset Search
 

 

Article

Triggers in a Distributed Perforce Environment

« Go Back

Information

 
Problem
How do I get change triggers to fire on Edge Server's in a Distributed Perforce environment?
 
Solution
With a Distributed Perforce service and its commit and edge server architecture, a submit is a cooperative process between the Edge and Commit server with new trigger types available for use on the Edge Server. 

New Triggers

Two new trigger types are available:
  • edge-submit: Execute pre-submit trigger on the Edge Server after changelist creation but prior to file transfer from the client to the Edge Server
  • edge-content: Execute mid-submit trigger after file transfer from the client to the Edge Server but prior to file transfer from Edge Server to Commit Server. Note, at this point the changelist will appear to be (and in fact is) shelved
Additionally, form-inform-out, and form-save triggers run on Edge Servers when the commands that trigger them are processed by the Edge Server.


kA0F0000000CqnAKAS_en_US_4_0



With edge-submit and edge-content triggers, we now have the chance to inspect a submit and reject it before the transfer from Edge Server to the Commit Server even starts. Once the submit reaches the Commit Server, we can do any necessary validation using the standard change triggers.

Trigger Invocation

The following is the sequence of triggers that are run during an Edge Server submit:
  1. During changelist construction, form triggers run on the Edge Server only:
    1. form-out 
    2. form-in 
    3. form-save 
  2. Edge triggers run on the Edge Server only:
    1. edge-submit 
    2. edge-content 
  3. Submit triggers run on the Commit Server only:
    1. change-submit 
    2. change-content 
    3. change-commit 
    4. change-failed
As is the case with a classic Perforce Server, the form triggers do not run in the case of p4 submit -c and p4 submit -e. 

The edge triggers run one right after the next, at the very start of the submit, in the case of p4 submit -e on the Edge Server; otherwise, the edge triggers run immediately before, and immediately after, the edge submit logic shelves the pending change on the Edge Server. 


Summary

 
Trigger TypeWhen it is calledExample use case
edge-submitWhen the submit starts but before the files are transferred. Useful for tasks that want to approve or reject a submit before the file transfer starts.Inspect changelist metadata and make sure user has provided all encessary information in the description or has included the right combination of files. 

You can apply edge server-specific checks at this point.
edge-contentAfter files are transferred but before the changelist moves to the commit server.Inspect files to be committed and make sure they have appropriate copyright headers. 

You can apply edge server-specific checks at this point.
change-submit(Post-transfer to commit server) When the submit starts but before the files are available for inspection. Note that on a commit server, file content will always be en route from the edge server.Apply any metadata checks that cannot be done on edge servers. Perhaps the commit server can interface with a defect tracking system but the edge servers cannot. 
change-content(Post-transfer to the commit server) After files are available but before the submit completes.Apply any content checks that cannot be done on edge servers. Perhaps the commit server can use Black Duck scanner but the edge server cannot.
change-commitWhen the submit is finished. Cannot block a submit but useful for responding to commits. Post-processing: launch a review of a completed commit. 
change-failedExecutes only if the changelist commit failed.Clean up artifacts of a failed submit.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255