NAME
Git::Repository::Plugin::GitHooks - A Git::Repository plugin with some goodies for hook developers
VERSION
version 2.6.0
SYNOPSIS
# load the plugin
use Git::Repository 'GitHooks';
my $git = Git::Repository->new();
my $config = $git->get_config();
my $branch = $git->get_current_branch();
my @commits = $git->get_commits($oldcommit, $newcommit);
my $files_modified_by_commit = $git->filter_files_in_index('AM');
my $files_modified_by_push = $git->filter_files_in_range('AM', $oldcommit, $newcommit);DESCRIPTION
This module adds several methods useful to implement Git hooks to Git::Repository.
In particular, it is used by the standard hooks implemented by the Git::Hooks framework.
NAME
Git::Repository::Plugin::GitHooks - Add useful methods for hooks to Git::Repository
CONFIGURATION VARIABLES
CONFIG_ENCODING
Git configuration files usually contain just ASCII characters, but values and sub-section names may contain any characters, except newline. If your config files have non-ASCII characters you should ensure that they are properly decoded by specifying their encoding like this:
$Git::Repository::Plugin::GitHooks::CONFIG_ENCODING = 'UTF-8';The acceptable values for this variable are all the encodings supported by the Encode module.
METHODS FOR THE GIT::HOOKS FRAMEWORK
The following methods are used by the Git::Hooks framework and are not intended to be useful for hook developers. They're described here for completeness.
prepare_hook NAME, ARGS
This is used by Git::Hooks::run_hooks to prepare the environment for specific Git hooks before invoking the associated plugins. It's invoked with the arguments passed by Git to the hook script. NAME is the script name (usually the variable $0) and ARGS is a reference to an array containing the script positional arguments.
load_plugins
This loads every plugin configured in the githooks.plugin option.
invoke_external_hooks ARGS...
This is used by Git::Hooks::run_hooks to invoke external hooks.
post_hooks
Returns the list of post hook functions registered with the post_hook method below.
METHODS FOR HOOK DEVELOPERS
The following methods are intended to be useful for hook developers.
post_hook SUB
Plugin developers may be interested in performing some action depending on the overall result of every check made by every other hook. As an example, Gerrit's patchset-created hook is invoked asynchronously, meaning that the hook's exit code doesn't affect the action that triggered the hook. The proper way to signal the hook result for Gerrit is to invoke it's API to make a review. But we want to perform the review once, at the end of the hook execution, based on the overall result of all enabled checks.
To do that, plugin developers can use this routine to register callbacks that are invoked at the end of run_hooks. The callbacks are called with the following arguments:
HOOK_NAME
The basename of the invoked hook.
GIT
The Git::Repository object that was passed to the plugin hooks.
ARGS...
The remaining arguments that were passed to the plugin hooks.
The callbacks may see if there were any errors signalled by the plugin hook by invoking the get_errors method on the GIT object. They may be used to signal the hook result in any way they want, but they should not die or they will prevent other post hooks to run.
cache SECTION
This may be used by plugin developers to cache information in the context of a Git::Repository object. SECTION is any string which becomes associated with a hash-ref. The method simply returns the hash-ref, which can be used by the caller to store any kind of information. Plugin developers are encouraged to use the plugin name as the SECTION string to avoid clashes.
get_config [SECTION [VARIABLE]]
This groks the configuration options for the repository by invoking git config --list. The configuration is cached during the first invocation in the object Git::Repository object. So, if the configuration is changed afterwards, the method won't notice it. This is usually ok for hooks, though, which are short-lived.
With no arguments, the options are returned as a hash-ref pointing to a two-level hash. For example, if the config options are these:
section1.a=1
section1.b=2
section1.b=3
section2.x.a=A
section2.x.b=B
section2.x.b=CThen, it'll return this hash:
{
'section1' => {
'a' => [1],
'b' => [2, 3],
},
'section2.x' => {
'a' => ['A'],
'b' => ['B', 'C'],
},
}The first level keys are the part of the option names before the last dot. The second level keys are everything after the last dot in the option names. You won't get more levels than two. In the example above, you can see that the option "section2.x.a" is split in two: "section2.x" in the first level and "a" in the second.
The values are always array-refs, even it there is only one value to a specific option. For some options, it makes sense to have a list of values attached to them. But even if you expect a single value to an option you may have it defined in the global scope and redefined in the local scope. In this case, it will appear as a two-element array, the last one being the local value.
So, if you want to treat an option as single-valued, you should fetch it like this:
$h->{section1}{a}[-1]
$h->{'section2.x'}{a}[-1]If the SECTION argument is passed, the method returns the second-level hash for it. So, following the example above:
$git->get_config('section1');This call would return this hash:
{
'a' => [1],
'b' => [2, 3],
}If the section doesn't exist an empty hash is returned. Any key/value added to the returned hash will be available in subsequent invocations of get_config.
If the VARIABLE argument is also passed, the method returns the value(s) of the configuration option SECTION.VARIABLE. In list context the method returns the list of all values or the empty list, if the variable isn't defined. In scalar context, the method returns the variable's last value or undef, if it's not defined.
As a special case, options without values (i.e., with no equals sign after its name in the configuration file) are set to the string 'true' to force Perl recognize them as true booleans.
get_config_boolean SECTION VARIABLE
Git configuration variables may be grokked as booleans. (See git help config.) There are specific values meaning true (viz. yes, on, true, 1, and the absense of a value) and specific values meaning false (viz. no, off, false, 0, and the empty string).
This method checks the variable's value and returns 1 or 0 representing boolean values in Perl. If the variable's value isn't recognized as a Git boolean the method croaks. If the variable isn't defined the method returns undef.
In the Git::Hooks documentation, all configuration variables mentioning a BOOL value are grokked with this method.
get_config_integer SECTION VARIABLE
Git configuration variables may be grokked as integers. (See git help config.) They may start with an optional signal (+ or -), followed by one or more decimal digits, and end with an optional scaling factor letter, viz. k (1024), m (1024*1024), or g (1024*1024*1024). The scaling factor may be in lower or upper-case.
This method checks the variable's value format and returns the corresponding Perl integer. If the variable's value isn't recognized as a Git integer the method croaks. If the variable isn't defined the method returns undef.
In the Git::Hooks documentation, all configuration variables mentioning an INT value are grokked with this method.
fault MESSAGE INFO
This method should be used by plugins to record consistent error or warning messages. It gets one or two arguments. MESSAGE is a one line string. INFO is an optional hash-ref which may contain additional information about the message with the following keys:
prefix
A string giving contextual information about the error message. It's used as a prefix to the message. When absent, the prefix used is the package name of the function which called
fault, which is usually a Git::Hooks plugin name. So, the actual error message looks like this:[PREFIX] MESSAGEdetails
A string containing details about the error message. If present, it is appended to the line above, separated by an empty line, and with its lines prefixed by two spaces, like this:
[PREFIX] MESSAGE DETAILS MORE DETAILS...
The method simply records the formatted error message and returns. It doesn't die.
get_faults
This method returns a string specially formatted with all error messages recorded with the fault method, a header, and a footer, if requested by configuration.
error PREFIX MESSAGE [DETAILS]
This method is DEPRECATED. Please, use fault instead.
get_errors
This method is DEPRECATED. Please, use get_faults instead.
undef_commit
The undefined commit is a special SHA-1 used by Git in the update and pre-receive hooks to signify that a reference either was just created (as the old commit) or has been just deleted (as the new commit). It consists of 40 zeroes.
empty_tree
The empty tree represents an empty directory for Git.
get_commit COMMIT
Returns a Git::Repository::Log object representing COMMIT.
get_commits OLDCOMMIT NEWCOMMIT [OPTIONS [PATHS]]
Returns a list of Git::Repository::Log objects representing every commit reachable from NEWCOMMIT but not from OLDCOMMIT.
There are two special cases, though:
If NEWCOMMIT is the undefined commit, i.e., '0000000000000000000000000000000000000000', this means that a branch, pointing to OLDCOMMIT, has been removed. In this case the method returns an empty list, meaning that no new commit has been created.
If OLDCOMMIT is the undefined commit, this means that a new branch pointing to NEWCOMMIT is being created. In this case we want all commits reachable from NEWCOMMIT but not reachable from any other branch. The syntax for this is NEWCOMMIT ^B1 ^B2 ... ^Bn", i.e., NEWCOMMIT followed by every other branch name prefixed by carets. We can get at their names using the technique described in, e.g., this discussion.
The Git::Repository::Log objects are constructed ultimately by invoking the git log command like this:
git log [<options>] <revision range> [-- <paths>]The revision range is usually just OLDCOMMIT..NEWCOMMIT, but there are some special cases which require some calculating as discussed above.
The OPTIONS optional argument is an array-ref pointing to an array of strings, which will be passed as options to the git-log command. It may be useful to grok some extra information about each commit (e.g., using --name-status).
The PATHS optional argument is an array-ref pointing to an array of strings, which will be passed as pathspecs to the git-log command. It may be useful to filter the list of commits, grokking only those affecting specific paths in the repository.
read_commit_msg_file FILENAME
Returns the relevant contents of the commit message file called FILENAME. It's useful during the commit-msg and the prepare-commit-msg hooks.
The file is read using the character encoding defined by the i18n.commitencoding configuration option or utf-8 if not defined.
Some non-relevant contents are stripped off the file. Specifically:
diff data
Sometimes, the commit message file contains the diff data for the commit. This data begins with a line starting with the fixed string
diff --git a/. Everything from such a line on is stripped off the file.comment lines
Every line beginning with a
#character is stripped off the file.trailing spaces
Any trailing space is stripped off from all lines in the file.
trailing empty lines
Any empty line at the end is stripped off from the file, making sure it ends in a single newline.
All this cleanup is performed to make it easier for different plugins to analyze the commit message using a canonical base.
write_commit_msg_file FILENAME, MSG, ...
Writes the list of strings MSG to FILENAME. It's useful during the commit-msg and the prepare-commit-msg hooks.
The file is written to using the character encoding defined by the i18n.commitencoding configuration option or utf-8 if not defined.
An empty line (\n\n) is inserted between every pair of MSG arguments, if there is more than one, of course.
get_affected_refs
Returns the list of names of the references affected by the current push command. It's useful in the update and the pre-receive hooks.
get_affected_ref_range REF
Returns the two-element list of commit ids representing the OLDCOMMIT and the NEWCOMMIT of the affected REF.
get_affected_ref_commits REF [OPTIONS [PATHS]]
Returns the list of commits leading from the affected REF's NEWCOMMIT to OLDCOMMIT. The commits are represented by Git::Repository::Log objects, as returned by the get_commits method.
The optional arguments OPTIONS and PATHS are passed to the get_commits method.
filter_files_in_index FILTER
Returns a list of the names of the files that are changed in the index (staging area) compared to the HEAD commit. It's useful in the pre-commit hook when you want to know which files are being modified in the upcoming commit.
FILTER specifies in which kind of changes you're interested in. It's passed as the argument to the --diff-filter option of git diff-index, which is documented like this:
--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
Select only files that are Added (A), Copied (C), Deleted (D), Modified
(M), Renamed (R), have their type (i.e. regular file, symlink,
submodule, ...) changed (T), are Unmerged (U), are Unknown (X), or have
had their pairing Broken (B). Any combination of the filter characters
(including none) can be used. When * (All-or-none) is added to the
combination, all paths are selected if there is any file that matches
other criteria in the comparison; if there is no file that matches other
criteria, nothing is selected.filter_files_in_range FILTER FROM TO [OPTIONS [PATHS]]
Returns a list of the names of the files that are changed between commits FROM and TO. It's useful in the update and the pre-receive hooks when you want to know which files are being modified in the commits being received by a git push command.
FILTER specifies in which kind of changes you're interested in. Please, read about the filter_files_in_index method above.
FROM and TO are revision parameters (see git help revisions) specifying two commits. They're passed as arguments to the git diff-tree command in order to compare them and grok the files that differ between them.
A special case occurs when FROM is the undefined commit, which happens when we're calculating the commit range in a pre-receive or update hook and a new branch or tag has been pushed. In this case we pass FROM and TO to the get_commits method to find the list of new commits being pushed and calculate the difference between the first commit's parent and TO. When the first commit has no parent (in case it's a root commit) we return an empty list.
The optional arguments OPTIONS and PATHS are passed to the get_commits method.
filter_files_in_commit FILTER, COMMIT
Returns a list of the names of the files that are changed in COMMIT. It's useful in the patchset-created and the draft-published hooks when you want to know which files are being modified in the single commit being received by a git push command.
FILTER specifies in which kind of changes you're interested in. Please, read about the filter_files_in_index method above.
COMMIT is a revision parameter (see git help revisions) specifying the commit. It's passed a argument to git diff-tree in order to compare it to its parents and grok the files that changed in it.
Merge commits are treated specially. Only files that are changed in COMMIT with respect to all of its parents are returned. The reasoning behind this is that if a file isn't changed with respect to one or more of COMMIT's parents, then it must have been checked already in those commits and we don't need to check it again.
authenticated_user
Returns the username of the authenticated user performing the Git action. It groks it from the githooks.userenv configuration variable specification, which is described in the Git::Hooks documentation. It's useful for most access control check plugins.
repository_name
Returns the repository name as a string. Currently it knows how to grok the name from Gerrit and Bitbucket servers. Otherwise it tries to grok it from the GIT_DIR environment variable, which holds the path to the Git repository.
get_current_branch
Returns the repository's current branch name, as indicated by the git symbolic-ref HEAD command.
If the repository is in a detached head state, i.e., if HEAD points to a commit instead of to a branch, the method returns undef.
get_sha1 REV
Returns the SHA1 of the commit represented by REV, using the command
git rev-parse --verify REVIt's useful, for instance, to grok the HEAD's SHA1 so that you can pass it to the get_commit method.
get_head_or_empty_tree
Returns the string "HEAD" if the repository already has commits. Otherwise, if it is a brand new repository, it returns the SHA1 representing the empty tree. It's useful to come up with the correct argument for, e.g., git diff during a pre-commit hook. (See the default pre-commit.sample script which comes with Git to understand how this is used.)
blob REV, FILE, ARGS...
Returns the name of a temporary file into which the contents of the file FILE in revision REV has been copied.
It's useful for hooks that need to read the contents of changed files in order to check anything in them.
These objects are cached so that if more than one hook needs to get at them they're created only once.
By default, all temporary files are removed when the Git::Repository object is destroyed.
Any remaining ARGS are passed as arguments to File::Temp::newdir so that you can have more control over the temporary file creation.
If REV:FILE does not exist or if there is any other error while trying to fetch its contents the method dies.
file_size REV FILE
Returns the size (in bytes) of FILE (a path relative to the repository root) in revision REV.
is_ref_enabled REF, SPECs...
Returns a boolean indicating if REF matches one of the ref-specs in SPECS. REF is the complete name of a Git ref and SPECS is a list of strings, each one specifying a rule for matching ref names.
As a special case, it returns true if REF is undef or if there is no SPEC whatsoever, meaning that by default all refs/commits are enabled.
You may want to use it, for example, in an update, pre-receive, or post-receive hook which may be enabled depending on the particular refs being affected.
Each SPEC rule may indicate the matching refs as the complete ref name (e.g. refs/heads/master) or by a regular expression starting with a caret (^), which is kept as part of the regexp.
match_user SPEC
Checks if the authenticated user (as returned by the authenticated_user method above) matches the specification, which may be given in one of the three different forms acceptable for the githooks.admin configuration configuration option, i.e., as a username, as a @group, or as a ^regex.
im_admin
Checks if the authenticated user (again, as returned by the authenticated_user method) matches the specifications given by the githooks.admin configuration variable. This is useful to exempt "administrators" from the restrictions imposed by the hooks.
SEE ALSO
Git::Repository::Plugin, Git::Hooks.
AUTHOR
Gustavo L. de M. Chaves <gnustavo@cpan.org>
COPYRIGHT AND LICENSE
This software is copyright (c) 2018 by CPqD <www.cpqd.com.br>.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.