Triggers (was: Re: Defect trackers and Perforce)

[Brad_Appleton-GBDA001 at email.mot.comBrad_Appleton-GBDA001]

Herb Maeder writes:

> Where can I find out more about triggers?

One of the earlier uses of the concept is in database systems.
You might try looking there.

But its an extremely simple concept and implementation for the
most part. A trigger is just an empty internal hook or placeholder
where you are allowed to specify additional actions to take place.
A really simple script which allowed a user-supplied trigger based on
environment variables might look something like:

  #!/usr/bin/perl
  #
  # something - some command
  #

  ## Look for a preprocessing trigger
  if (exists $ENV{PRE_SOMETHING_TRIGGER}) {
      ## The user specified an action for us to execute here
      system($ENV{PRE_SOMETHING_TRIGGER});

      ## Now look at the exit status and see if we should continue
      if (<the command failed>) {
          ... give some message and abort
      }
  }

  ## Now go do what this command is supposed to do
  ...

  ### Now look for a postprocessing trigger
  if (exists $ENV{POST_SOMETHING_TRIGGER}) {
      ## The user specified an action for us to execute here
      system($ENV{POST_SOMETHING_TRIGGER});

      ...
  }


If you're familiar with the term "callback" in C/C++ or GUI programming,
its basically the same thing. The software application has some pre-defined
sequence points and permits the user to specify additional actions that
are carried out in those "hot spots" defined by the sequence points.
By default, there are no additional actions to execute, but the user may
add whatever is needed as a frontend and/or backend to what the particular
operation does.

Thats pretty much the long and short of it - it certainly doesn't require
a Ph.D. in rocket science or anything like that. The important things
you need to be concerned with when an SCM/VC tool provides triggers are:

   - How much overhead (resources and performance) does it cost you
     you if the tool provides the ability to add triggers where you
     don't need/want them? P4 has a reputation for speed. We certainly
     wouldn't want our checkouts to happen any slower just because p4
     was giving us the ability to add triggers that we aren't using.

  - How much overhead does it cost you if you *do* use the trigger?
    (aside from the overhead of the trigger-action performed, how much
    more time does it take to look for the trigger, spawn a process
    to fire the trigger, and then check the result)

  - What is the granularity of the trigger? Is it file-based, or
   event-based, or transaction based?  For example, if I checkout
   multiple files in a single command, does the trigger fire once
   for each checkout of each file or once for the entire command?

  - What contextual information do my triggers have access to? Can I
    find out what the command that executed is? How about the command-line
    arguments? How about the parent event that triggered my trigger (if any)?
    What about the location of the depot or the full path to the checkedout
    file or the name of the job or the environment of the command (etc.)?

  - WHERE are the trigger points (which commands that I'm interested in
    "tailoring" allow me to specify triggers, and where in the sequence
    of the execution do the triggers fire? Can I attach more than one
    trigger to a given sequence point and if so in what order do the
    triggers fire).

As for the specific answers to each of these questions for Perforce
triggers and the interface provided for them, I'll have to let someone
from Perforce speak to that.

A typical use of a "pre-event" trigger might be for access control.
I may want to prevent checkout of a file, or of all files in a directory,
unless the user is one of a select set of usernames, or maybe I only
want to allow them to checkout foo.x if and only if foo.y is already
checked out (or maybe I want to prevent anyone from checking out ANY
VERSION of foo.c if at least one version of it is already checked out
somewhere). Or maybe I want to ensure that all checkouts or job
creations have a corresponding change-ID in the external tracking
system (I might prompt for it interactively, or look for it in
an environment variable).

A typical use of a post-event trigger would be for notification, or
logging. If a file is checkedout by someone already, then maybe I
want to send email to everyone that has it checked-out to let them
know that yet another person has checked out that file. Or maybe, when
a p4 job is successfully submitted, I want to cause a state-transition
(perhaps to the CLOSED state) for the corresponding defect in a tracking
system, or maybe I want to trigger an automatic merge to another branch,
or just log to a file somewhere that the job needs to be integrated into
that branch.

One kind of trigger that I rarely see tools offer (even those that have
triggers implemented) is a failure trigger. Maybe I set-up some things
with a pre-event trigger that a post-event trigger would clean-up,
but because a failure occurred somewhere between the two, I don't want
to leave that stuff lying around. You can think of this as somehwat
akin to a rollback or recovery mechanism for a database transaction.

Hope that helps!
- -- 
Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/
 "And miles to go before I sleep."   |  3700+ WWW links on CS & Sw-Eng