Triggering on pushes and fetches
There is no requirement that any triggers be run at any point in the submission or push process.
to run trigger scripts when the
p4 fetch commands are
invoked, use push triggers of type
This section describes the triggers that can be used when initiating a push or fetch for Perforce DVCS.
For a description of the triggers that can be used by the server receiving the pushed items or responding to the fetch request, see Additional triggers for push and fetch commands.
Similarity between p4 submit and p4 push
During a push, the local server acts as the client of the shared server. Therefore, there are similarities between submits and pushes:
- Push actions are atomic: either everything is pushed or nothing is pushed.
- Pushes occur in three distinct phases and different types of push triggers are appropriate for each phase.
The following figure:
- illustrates the similarities between submits and pushes
- illustrates the path of submitted files, via a changelist, from the client, to the local server, and finally, to the shared server
- includes all possible types of triggers and shows the types of triggers that can be run during each phase of these processes.
Change and push triggers
Three phases of submits and pushes:
|(1) Send metadata||(2) Send files||
Cannot access file contents.
Can access file contents by using the revision specifier
Cannot revoke the commit.
|A trigger might test to see whether the user is allowed to perform the action or whether the file type is allowed.||A trigger might parse the contents of the files and take appropriate action. One possibility is to determine whether the submitted files adhere to coding conventions.||A trigger might send a notification, or do some clean up.|
Differences between p4 submit and p4 push
Differences between submits and pushes:
- While both submits and pushes are atomic
- a submit encompasses a single changelist
- push can contain multiple changelists. Thus the failure of a push is more costly.
- Submits are unidirectional.
- Pushes are the result
p4 fetch, or
p4 unzipand are bidirectional. Depending on the command that causes the trigger to execute, either the local server or the shared server might play the role of client.
- During the first phase of a push, metadata is read into memory, which
limits the data that the
push-committrigger can access. Each
push-committrigger is a separate process with its own memory. See Push-submit triggers.
- If a submit fails, you’re left with work in progress that you can change and retry. Having a push operation fail requires that you retrace your steps prior to the submit to the local server. For this reason, you might want to run triggers during the submit operation rather than the push operation if possible.
- Change triggers are involved in the processing of
p4 submitcommands only. Push triggers are invoked in the context of three somewhat different scenarios: the execution of
p4 fetch, or
You should keep these differences in mind when you decide how to define your triggers and at what stage to run them.
Fields on a p4 push trigger
The following table describes the fields of a push trigger. For sample definitions, see the subsequent sections, describing each push trigger type.
The name of the push trigger.
A file pattern in depot syntax.
When a user uses the
The trigger for the
to run when a user invokes the
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
Even when a
trigger script succeeds, the submission that caused the trigger to run
can fail because of subsequent trigger failures, or for other reasons.
push-content triggers only
for validation, and use
push-commit triggers for
operations that are contingent on the successful completion of the push