Git-Hooks

 view release on metacpan or  search on metacpan

lib/Git/Hooks/CheckJira.pm  view on Meta::CPAN

  [githooks]

    # Enable the plugin
    plugin = CheckJira

    # These users are exempt from all checks
    admin = joe molly

  [githooks "checkjira"]

    # Configure the URL and the admin credentials to interact with the Jira
    # server.
    jiraurl = https://jira.example.net
    jirauser = jiradmin
    jirapass = my-secret

    # Look for Jira keys at the beginning of the commit messages title, enclosed
    # in brackets.
    matchlog = (?s)^\\[([^]]+)\\]

    # Impose restrictions on valid Jira issues

lib/Git/Hooks/Tutorial.pod  view on Meta::CPAN

constraining.

I disable the C<githooks.abort-commit> option so that C<pre-commit> and
C<commit-msg> hooks don't abort the commit in case of errors. That's because I
find it easier to amend the commit than to remember to recover my carefully
crafted commit message from the F<.git/COMMIT_EDITMSG> file afterwards.

The section C<githooks "checkjira"> contains some global configuration for the
C<CheckJira> plugin, which I enable only for some repositories. Since the
C<CheckJira> plugin has to connect to our Jira server, it needs the server URL
and some credentials to authenticate. The C<matchlog> regex makes Jira issue
keys be looked for only inside a pair of brackets at the beginning of the commit
messages's title line.

I enable other plugins for specific repositories, since they depend on the
context in which they are developed.

At L<CPQD|http://www.cpqd.com.br/> we use
L<Jira|http://www.atlassian.com/software/jira> and
L<Gerrit|https://code.google.com/p/gerrit/>. So, for my work-related
repositories I have this in their F<.git/config>:

lib/Git/Hooks/Tutorial.pod  view on Meta::CPAN

    [githooks "checkjira"]
            jiraurl  = https://jira.cpqd.com.br
            jirauser = gustavo
            jirapass = a-very-large-and-difficult-to-crack-password
            matchlog = (?s)^\\[([^]]+)\\]
    [githooks "checklog"]
            title-max-width = 62

In the server the C<CheckCommit>, C<CheckJira>, and C<CheckLog> plugins are
enabled for every repository. The <githooks.checkjira> section specifies the URL
and credentials of the Jira server as well as where in the commit message the
Jira references are to be looked for.

The C<githooks.checkcommit> enables the C<email-valid> check to guarantee that
authors and committers use sane email addresses in their commits.

The C<githooks.checklog> section specifies a nonstandard value for the
C<title-max-width> option.

As the administrator, I've configured myself (C<githooks.admin = gustavo>) to be
exempt from any checks so that I can brag about my superpowers to my fellow

lib/Git/Hooks/Tutorial.pod  view on Meta::CPAN

You have to do a little extra configuration in the C<githooks.gerrit> section:

    [githooks "gerrit"]
            url  = https://gerrit.cpqd.com.br
            username = gerrit
            password = a-very-large-and-difficult-to-crack-password
            votes-to-approve = Verification+1
            votes-to-reject = Verification-1

The three options C<url>, C<username>, and C<password> tell where to connect to
Gerrit and with which user's credentials. This is the user that will appear to
be making comments and reviewing the patchsets.

Then you have to tell Git::Hooks how it should vote to approve and to reject a
change using the options C<votes-to-approve> and C<votes-to-reject>. In the
example above you tell Git::Hooks to cast a +1 in the C<Verification> label to
approve the change and to cast a -1 in the same label to reject it. You may cast
multiple votes in multiple labels by separating the vote specifications with
commas.

Gerrit has a notion of a hierarchy of repositories (called 'projects' in