How can I test my pre-receive hook?

user_1783632 0
Viewed 2439

I need to create a pre-receive hook that rejects push from any client from any branch which is not master, So I wrote this script:

     #!/bin/bash

    refname="$0"
    oldrev="$1"
    newrev="$2"

    alowed_branch='master'
    current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

    if [ $alowed_branch = $current_branch ]
    then
      echo "you are pushing to master branch"
      exit 0
    else
      echo Branch $current_branch is Locked.
     exit 1
    fi

Now I don't know how can I test it...

When tested on a 'pre-commit' hook on my local git repo I get what I want:

enter image description here

But when trying to test it as a pre-push or pre-receive hook as suggested it doesn't take any effect and I can commit and push with no interference.

is there a way to test it on GitHub?

githooks git
1 Answers

Testing hooks, especially pre-receive hooks, is difficult: they run in unusual environments. There are few good ways to test them (the main good way is a sacrificial repository or two).

You have a number of intertwining problems here:

refname="$0"

This is just wrong no matter what, as in a shell script, $0 refers to the name of the script itself.

current_branch=$(refname)

This, which you deleted in an edit, was also wrong: it tries to run the command refname. So it's good that you replaced it, but:

current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

This is subtly wrong: if your current branch is named fixes/bug-123 it will set current_branch to bug-123, not fixes/bug-123.

To get the current branch name as a symbolic reference minus the refs/heads/ part, use:

current_branch=$(git symbolic-ref --short HEAD) || exit 1

The --short directs git symbolic-ref to omit the refs/heads/ part, and the || exit 1 directs the shell to exit (with failure status) if git symbolic-ref itself fails, which it could: if you have a "detached HEAD", HEAD is not a symbolic ref, and Git will complain about that and current_branch will be set to the empty string.

Now, with those out of the way, you mention:

... trying to test it as a pre-push or pre-receive hook ...

As a pre-push hook, $1 and $2 (which you store in oldrev and newrev) would actually be set to the name and URL of the remote! The old and new revision IDs, and the old and new reference names, are passed to that hook as its standard input. This all happens on the client side, after connecting to the other Git (the remote) but before sending anything. (See the section on pre-push hooks in the githooks documentation.)

As a pre-receive hook, $1 and $2 would not be set to anything at all (which is OK since you never use the variables anyway). The current branch would be the current branch in the other Git on the remote. A pre-receive hook, like a pre-push hook, must read its standard input, one line at a time, checking each group of parameters supplied on that line. If the hook exits with a nonzero return, the entire push is rejected (from the server's side).

When checking reference names in a pre-push or pre-receive hook, be sure to check the entire reference: an incoming reference (in either hook) or outgoing reference (in a pre-push hook) can refer to a tag, for instance, as in refs/tags/v1.2, or a branch whose name includes slashes, as in refs/heads/feature/tall. Don't just chop off all but the last part of the name, nor the first two components without looking at them. And, in either hook, the current branch name is normally entirely irrelevant: someone running git push specifies which reference(s) to push on the command line:

git push origin \
  refs/heads/master:refs/for/master \
  refs/tags/v1.2:refs/tags/v1.2 \
  refs/notes/commits:refs/notes/commits \
  refs/peculiar-ref:refs/even-stranger/master

for instance. None of these is going into a branch on the target; only one is from a branch on the source.

(Note that hooks can be written in any language that can run on the machine on which that particular Git is installed. They don't have to be bash / sh scripts—though if you have Git you must have a shell, since parts of Git are written in shell. Always beware of hardcoded paths: for instance, bash may be located in /usr/local/bin/bash rather than /bin/bash on some systems.)

user_12564520
Related