Triggering with depots of type graph

To associate the trigger with a single repo named //graphDepot1/repo8, specify the path as //graphDepot1/repo8/…​ with /…​ at the end.

To associate the trigger with multiple repos, such as //graphDepot1/repoA and //graphDepot2/repoB, use asterisks (*) to specify //graphDepot*/repo*/…​ as the path.

For information about depots of type graph, see Working with Git.

Four variables apply:

  • %depotName% - The depot the repo resides in
  • %repoName% - The name of the repo
  • %repo% - The repo, which has .git as a suffix, but otherwise is identical to %repoName%
  • %pusher% - The user credited with the push

The following types of graph triggers are described in the order they would normally execute: graph-push-start, graph-push-reference, graph-push-reference-completegraph-push-complete

See also the Example of checking a commit

graph-push-start

  • Fires prior to any data being transferred as part of a git push operation through the connector
  • Can enforce your workflow rules

graph-push-reference

  • Fires for each reference that is being created or updated
  • Can have logic to block the update, according to your workflow rules
  • If the trigger fails on any reference, the entire push is canceled

A graph-push-reference trigger passes the original reference value in the %oldValue% variable, the new value in the %newValue% variable, and the reference name in %reference%.

When such a trigger is fired from a push to the Git Connector:

  • the reference type is passed in the %refType% variable.
  • the %refFlags% variable is populated with a list of actions that are being applied to the reference.

graph-push-reference-complete

  • Fires after a reference has been created or updated as part of a git push operation through the connector
  • Same variables as graph-push-reference
  • Any trigger failures are ignored

graph-push-complete

  • Fires when a git push of a specified repo has successfully completed
  • You can use this trigger to signal that all the files are present and ready for a build, testing, or diagnostic tool.

Example of checking a commit

Suppose that the use case for a trigger is to enforce a business rule such as the following:

Your organization requires that all commits include a "Description" with a issue tracking number or BugIdNumber, such as P4-17870, or a Perforce Job Number, such as job097329.

The trigger code might be as follows.

#!/bin/bash
reference=$1
oldValue=$2
newValue=$3
refType=$4
pusher=$5
refFlags=$6
logFile='/home/perforce/triggers/helix4git/checkCommit.log'
time=`date`
echo "$time " >> $logFile
echo "Depot: $depotName" >> $logFile
echo "Repo: $repoName" >> $logFile
echo "Reference: $reference" >> $logFile
echo "oldValue: $oldValue" >> $logFile
echo "newValue: $newValue" >> $logFile
echo "refType: $refType" >> $logFile
echo "Pusher: $pusher" >> $logFile
echo "refFlags: $refFlags" >> $logFile
echo "" >> $logFile
requiredText="JIRA"
p4 graph cat-file commit $newValue >> $logFile
p4 graph cat-file commit $newValue | grep $requiredText >> $logFile
res=`p4 graph cat-file commit $newValue | sed -n "/$requiredText/p"`
if [ -n "$res" ] ; then
echo "contains the $requiredText job number" >> $logFile
exit 0
else
echo "NOT contains the $requiredText job number" >> $logFile
exit 1
fi

To call the trigger:

checkCommit graph-push-reference //repo/rtest/... "/home/perforce/triggers/helix4git/checkCommit.sh %reference% %oldValue% %newValue% %refType% %pusher% %refFlags%"