Form-commit triggers
Unlike the other form triggers, the form-commit
trigger
fires after a form is committed to the database. Use these triggers for
processes that assume (or require) the successful submission of a form.
In the case of job forms, the job’s name is not set until after the job
has been committed to the database; the form-commit
trigger
is the only way to obtain the name of a new job as part of the process of
job creation.
Example
The following script, when copied to newjob.sh, shows how to get a job name during the process of job creation, and also reports the status of changelists associated with job fixes.
#!/bin/sh # newjob.sh - illustrate form-commit trigger COMMAND=$0 USER=$1 FORM=$2 ACTION=$3 echo $COMMAND: User $USER, formname $FORM, action $ACTION >> log.txt
To use the trigger, add the following line to the trigger table:
sample10 form-commit job "newjob.sh %user% %formname% %action%"
Use the %action%
variable to distinguish whether or not a
change to a job was prompted by a user directly working with a job by
means of p4 job
, or indirectly by means of fixing
the job within the context of p4 fix
or the
Jobs
field of a changelist.
The simplest case is the creation of a new job (or a change to an
existing job) with the p4 job
command; the trigger
fires, and the script reports the user, the name of the newly-created
(or edited) job. In these cases, the %action%
variable is
null.
The trigger also fires when users add or delete jobs to changelists,
and it does so regardless of whether the changed jobs are being
manipulated by means of p4 fix
, p4 fix
-d
, or by editing the Jobs
field of the
changelist form provided by p4 change
or
p4 submit
form). In these cases, the
%action%
variable holds the status of the changelist
(pending
or submitted
) to which the jobs are
being added or deleted. The form-commit
trigger does not
run if zero jobs are attached to the changelist.
Because the %action%
variable is not always set, it must
be the last argument supplied to any form-commit
trigger
script.