[Mon Mar 5 22:47:34 PST 2001]
I’ve been testing this by taking two copies of the bitcluster tree, stuff the triggers into there, and testing on work and disks. I need to write some tests but have not done so yet.
[Thu Dec 14 19:40:09 PST 2000]
Basic trigger overview.
Event classes
pre-commit
- called before a changeset is committed
- exit !0 fails the commit
- typically used for integrity checks
post-commit
- called after a changeset is committed
- typically used for notification
pre-incoming
- called before an incoming push/pull is started
- exit !0 fails the incoming event
- typically used for locking down a repository
pre-resolve
- called after the data has been union-ed in the RESYNC directory
- called in the RESYNC directory, not the enclosing repository
- exit 0 allows the pull/push
- exit 1 fails the entire pull/push
- exit 2 fails the entire pull/push but leaves the patch in PENDING
- typically used to examine changes before taking them
pre-apply [ NOT IMPLEMENTED ]
- called in the RESYNC directory, not the enclosing repository
- called after the data has been merged in the RESYNC directory
but before it is applied to the tree. Last chance to say no,
allows examination of the merge changes
- exit 0 allows the pull/push
- exit 1 fails the entire pull/push
- exit 2 fails the pull/push but leaves the patch in PENDING
- exit 3 fails the pull/push but leaves the patch in PENDING and
the RESYNC tree in PENDING/RESYNC-<date>
- typically used to examine changes before taking them
post-incoming
- called after the data has been applied to the tree
- typically used for notification
pre-outgoing
- called before an outgoing pull/push/clone event
- exit !0 fails the outgoing event
- typically used for locking down a repository
post-outgoing
- called after the outgoing event
- typically used for notification
Missing triggers
- post-resolve; unlikely to be added, use pre-apply.
- post-apply; unlikely to be added, use post-incoming
- pre-delta; not implemented, will be implemented at some point
We need this for spelling/cstyle/whatever checks.
Difference between pre- and post-
pre-triggers may cause events to fail;
post-triggers are informational only.
Paranoid mode for gatekeeper trees
Because triggers can propagate and because they can do bad things like
"rm -rf .", it is a wise idea to put a non-propagating paranoid trigger
like so in your tree:
cat > BitKeeper/triggers/pre-apply-paranoid <<EOF
#!/bin/sh
# This is running in the RESYNC tree, we're looking for any new
# triggers and/or changes to triggers.
# Done after the resolve stage because they could be sneaky and create
# the file in an earlier changeset and then move it and we'd miss it
# because it hasn't been moved yet.
test `bk sfiles BitKeeper/triggers | wc -l` -gt 0 && {
echo Changes delayed until they are reviewed
exit 3
}
exit 0
Trigger categories:
c- -> pre-commit
c+ -> post-commit
i- -> pre-incoming
i+ -> post-incoming
o- -> pre-outgoing
o+ -> post-outgoing
r- -> pre-resolve
Trigger variable Valid in Meaning
---------------- -------- -------
BK_CSETLIST i+, o-, r- File containing list of cset revs.
BK_CSETS o-, o+ List of outgoing csets.
BK_EVENT All Event type, such as clone.
BK_HOST All Client host
BKD_HOST i-, i+, o-, o+ Server host
BK_LEVEL All The "level" of the client repository.
BKD_LEVEL i+, o-, o+ The "level" of the server repository.
BK_LOCALCSETS o-, o+ The number of csets in outgoing repo
not found in incoming repo.
BK_PENDING c-, c+ File containing the list of deltas
about to be committed.
BK_REMOTECSETS o-, o+ The number of csets in incoming repo
not found in outgoing repo.
BK_ROOT All Client root
BKD_ROOT i-, i+, o-, o+ Server root
BK_SIDE i-, i+, o-, o+ client|server, indicates which side is
running the trigger.
BK_STATUS c+, i+, o+ OK means the command worked,
other values mean an error or a
dry run.
BK_TIME_T All Date of the BK binary as a time_t.
BKD_TIME_T i-, i+, o-, o+ Date of server BK binary as a time_t.
BK_TRIGGER All The basename of the trigger program.
BK_USER All Client user
BKD_USER i-, i+, o-, o+ Server user
BK_UTC All Date of the BK binary as YYYYMMDDHHMMSS
BKD_UTC i-, i+, o-, o+ Date of the server BK binary
BK_VERSION All Version of the BK binary as the version
string which may be a symbolic tag. If
the BK version was not tagged, then the
UTC.
BKD_VERSION i-, i+, o-, o+ Version of the server BK binary.