Sitaram Chamarty e1c7e546aa cpu-time command -> CpuTime trigger module...

...now that triggers are not restricted to external programs and can be
perl code called by gitolite-shell (thus in the same PID), there's no
need to compute and pass along the times() array.

This also changes the arguments to POST_GIT; they're now the same as
PRE_GIT's.

2012-04-06 17:26:27 +05:30

3.2 KiB

Raw Blame History

gitolite triggers

intro and sample rc excerpt

Gitolite fires off external commands at 7 different times. The [rc][] file specifies what commands to run at each trigger point, but for illustration, here's an excerpt:

%RC = (

    <...several lines later...>

    # comment out or uncomment as needed
    # these will run in sequence after post-update
    POST_COMPILE                =>
        [
            'post-compile/ssh-authkeys',
            'post-compile/update-git-configs',
            'post-compile/update-gitweb-access-list',
            'post-compile/update-git-daemon-access-list',
        ],

    # comment out or uncomment as needed
    # these will run in sequence after a new wild repo is created
    POST_CREATE                 =>
        [
            'post-compile/update-git-configs',
            'post-compile/update-gitweb-access-list',
            'post-compile/update-git-daemon-access-list',
        ],

(As you can see, post-create runs 3 programs that also run from post-compile. This is perfectly fine, by the way)

manually firing triggers

...from the server command line is easy. For example:

gitolite trigger POST_COMPILE

However if the triggered code depends on arguments (see next section) this won't work. (The POST_COMPILE trigger programs all just happen to not require any arguments, so it works).

common arguments

Triggers receive the following arguments:

any arguments mentioned in the rc file (for an example, see the renice command in the PRE_GIT trigger sequence),
the name of the trigger as a string (example, "POST_COMPILE"), so you can call the same program from multiple triggers and it can know where it was called from,
followed by zero or more arguments specific to the trigger, as given in the next section.

trigger-specific arguments and other details

Here are the rest of the arguments for each trigger, plus a brief description of when the trigger runs:

ACCESS_1 runs after the first access check. Arguments:
- repo
- user
- 'R' or 'W'
- 'any'
- result: this is the result of the access() function. If it contains the uppercase word "DENIED", the access was rejected. Otherwise result contains the refex that caused the access to succeed.
ACCESS_2 runs after the second access check, in the update hook. Arguments:
- repo
- user
- any of W, +, C, D, WM, +M, CM, DM
- the ref being updated (e.g., 'refs/heads/master')
- result (see above)
PRE_GIT and POST_GIT run just before and after the git command. Arguments:
- repo
- user
- 'R' or 'W'
- 'any'
- the git command ('git-receive-pack', 'git-upload-pack', or 'git-upload-archive') being invoked.
PRE_CREATE and POST_CREATE run just before and after a new "[wild][]" repo is created by user action. Arguments:
- repo
- user
POST_COMPILE runs after an admin push has successfully "compiled" the config file. By default, the next thing is to update the ssh authkeys file, then all the 'git-config's, gitweb access, and daemon access.

No arguments.

3.2 KiB Raw Blame History