Git pre-push hooks
up vote
91
down vote
favorite
I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.
git hook
add a comment |
up vote
91
down vote
favorite
I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.
git hook
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55
add a comment |
up vote
91
down vote
favorite
up vote
91
down vote
favorite
I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.
git hook
I would like to run a unit-tests before every git push and if tests fails, cancel the push, but I can't even find pre-push hook, there is pre-commit and pre-rebase only.
git hook
git hook
asked Nov 16 '10 at 16:03
sheepwalker
5241616
5241616
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55
add a comment |
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55
add a comment |
7 Answers
7
active
oldest
votes
up vote
18
down vote
accepted
I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
|
show 3 more comments
up vote
183
down vote
Git got the pre-push
hook in the 1.8.2
release.
Sample pre-push
script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
add a comment |
up vote
19
down vote
Git got the pre-push hook in the 1.8.2 release.
Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.
And for an example on how to use (taken and adopted and enhanced from this nice entry)
Simple example to login to vagrant, run tests and then push
#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push
CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'
# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')
if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0
As you can see the example uses a protected branch, subject of the pre-push hook.
add a comment |
up vote
13
down vote
If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.
Edit
As of git 1.8.2 this answer is outdated. See manojlds's answer above.
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
add a comment |
up vote
7
down vote
There isn't a hook for it, because a push isn't an operation that modifies your repository.
You can do the checks on the receiving side though, in the post-receive
hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.
add a comment |
up vote
5
down vote
For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.
Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.
Finally, you could run your tests in your pre-commit
hook but check for what branch is being committed to. Then you could have a, say, a production
branch that requires all tests pass before accepting a commit but your master
doesn't care. limerick_rake may be useful in that scenario.
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
add a comment |
up vote
0
down vote
The script linked by the highly-voted answer shows the parameters etc to the pre-push
hook ($1
is remote name, $2
URL) and how to access the commits (lines read
from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>
)
#!/bin/sh
# An example hook script to verify what is about to be pushed. Called by "git
# push" after it has checked the remote status, but before anything has been
# pushed. If this script exits with a non-zero status nothing will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
# <local ref> <local sha1> <remote ref> <remote sha1>
#
# This sample shows how to prevent push of commits where the log message starts
# with "WIP" (work in progress).
remote="$1"
url="$2"
z40=0000000000000000000000000000000000000000
while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi
# Check for WIP commit
commit=`git rev-list -n 1 --grep '^WIP' "$range"`
if [ -n "$commit" ]
then
echo >&2 "Found WIP commit in $local_ref, not pushing"
exit 1
fi
fi
done
exit 0
add a comment |
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
18
down vote
accepted
I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
|
show 3 more comments
up vote
18
down vote
accepted
I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
|
show 3 more comments
up vote
18
down vote
accepted
up vote
18
down vote
accepted
I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.
I would rather run the test in a pre-commit-hook. Because the change is already recorded when committing. Push and pull only exchange information about already recorded changed. If a test fails you would already have a "broken" revision in your repository. Whether you're pushing it or not.
answered Nov 16 '10 at 16:48
ordnungswidrig
2,82011326
2,82011326
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
|
show 3 more comments
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
144
144
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I generally agree, though if you're in the habit of making a lot of incremental commits to squash later, and the test suite is large, this could be impractical.
– Cascabel
Nov 16 '10 at 18:03
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I see. So I would suggest the tests run before merging with the main branch but there is no pre-merge hook either. However there is an "update" hook wich can be used to prevent updating a ref in the remote repository: "Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. The hook executes once for each ref to be updated, and takes three parameters: the name of the ref being updated, the old object name stored in the ref, and the new objectname to be stored in the ref."
– ordnungswidrig
Nov 17 '10 at 8:27
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
I decided to make @ordnungswidrig variant - just use pre-commit hook, cause of "broken" revisions. Here is my variant (php + phpUntit tests): <pre>#!/bin/sh /usr/bin/php /srv/www/wf/tests/run.php /srv/www/wf/tests > /tmp/result if grep 'OK' /tmp/result then exit 0 else echo 'Your tests is failed, you cannot commit' exit 1 fi </pre>
– sheepwalker
Dec 8 '10 at 11:51
4
4
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
Down voted because - while informative - it completely ignores the OP's question.
– The Dembinski
Jan 16 '17 at 18:24
4
4
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
@calder.ty - Nah. manojlds better addresses what matters. In fact, pre-commit hooks that run tests are generally a bad idea imo. It assumes that all things that get committed must pass tests. Which is bad for common work flows that focus on collaboration. So yea...I disagree; its not a better way to do "it" nor does it address the question.
– The Dembinski
May 8 '17 at 16:16
|
show 3 more comments
up vote
183
down vote
Git got the pre-push
hook in the 1.8.2
release.
Sample pre-push
script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
add a comment |
up vote
183
down vote
Git got the pre-push
hook in the 1.8.2
release.
Sample pre-push
script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
add a comment |
up vote
183
down vote
up vote
183
down vote
Git got the pre-push
hook in the 1.8.2
release.
Sample pre-push
script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt
Git got the pre-push
hook in the 1.8.2
release.
Sample pre-push
script: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample
1.8.2 release notes talking about the new pre-push hook: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt
edited Mar 14 '13 at 4:15
answered Feb 3 '13 at 13:17
manojlds
210k46367357
210k46367357
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
add a comment |
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
1
1
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
Hey dude.. Thanks.. :)
– Gaurav Agarwal
Feb 6 '14 at 12:52
1
1
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@manojlds do you know what is this hook designed to be used for? I would like to use it to push my binary to my customers when pushing to a specific branch(i.e. build the nightly version and upload it with curl, before pushing). The problem is that it takes a while to build and upload, and remote closes connection. So i end up with my binary built and uploaded to customers but not pushed to a repo, because remote repo closes connection. Any idea how to work around this? Or maybe it is a bad idea in it's root.
– igrek
Jun 19 '14 at 13:51
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@igrek did you find a solution to the connection closing issue?
– Mario Estrada
Apr 27 '15 at 3:54
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
@MarioEstrada, yes, i don't remember exactly how, but i made it push twice: first git command runs unit tests and then if it doesn't disconnect it pushes and starts another push in another thread, if the first one push times out, the second one from another thread works for me. If either first and second succeeds, then the first pushes changes, and the second pushes nothing. The trick is that i had some argument added, which bypasses unit tests(which was used for the second git push, so it didn't start unit tests again)
– igrek
Apr 28 '15 at 7:12
4
4
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
This needs to be the accepted answer.
– The Dembinski
Jan 16 '17 at 18:25
add a comment |
up vote
19
down vote
Git got the pre-push hook in the 1.8.2 release.
Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.
And for an example on how to use (taken and adopted and enhanced from this nice entry)
Simple example to login to vagrant, run tests and then push
#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push
CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'
# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')
if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0
As you can see the example uses a protected branch, subject of the pre-push hook.
add a comment |
up vote
19
down vote
Git got the pre-push hook in the 1.8.2 release.
Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.
And for an example on how to use (taken and adopted and enhanced from this nice entry)
Simple example to login to vagrant, run tests and then push
#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push
CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'
# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')
if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0
As you can see the example uses a protected branch, subject of the pre-push hook.
add a comment |
up vote
19
down vote
up vote
19
down vote
Git got the pre-push hook in the 1.8.2 release.
Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.
And for an example on how to use (taken and adopted and enhanced from this nice entry)
Simple example to login to vagrant, run tests and then push
#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push
CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'
# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')
if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0
As you can see the example uses a protected branch, subject of the pre-push hook.
Git got the pre-push hook in the 1.8.2 release.
Pre-push hooks are what I needed along with pre-commit hooks. Apart from protecting a branch, they can also provide extra security combined with pre-commit hooks.
And for an example on how to use (taken and adopted and enhanced from this nice entry)
Simple example to login to vagrant, run tests and then push
#!/bin/bash
# Run the following command in the root of your project to install this pre-push hook:
# cp git-hooks/pre-push .git/hooks/pre-push; chmod 700 .git/hooks/pre-push
CMD="ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key 'cd /vagrant/tests; /vagrant/vendor/bin/phpunit'"
protected_branch='master'
# Check if we actually have commits to push
commits=`git log @u..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/(.*),1,')
if [[ $current_branch = $protected_branch ]]; then
eval $CMD
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "failed $CMD"
exit 1
fi
fi
exit 0
As you can see the example uses a protected branch, subject of the pre-push hook.
answered Jan 29 '14 at 14:57
Jimmy Kane
9,72465281
9,72465281
add a comment |
add a comment |
up vote
13
down vote
If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.
Edit
As of git 1.8.2 this answer is outdated. See manojlds's answer above.
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
add a comment |
up vote
13
down vote
If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.
Edit
As of git 1.8.2 this answer is outdated. See manojlds's answer above.
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
add a comment |
up vote
13
down vote
up vote
13
down vote
If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.
Edit
As of git 1.8.2 this answer is outdated. See manojlds's answer above.
If you are using the command line, the easiest way to do this is to write a push script that runs your unit tests and, if they succeed, completes the push.
Edit
As of git 1.8.2 this answer is outdated. See manojlds's answer above.
edited Jan 8 '14 at 17:23
answered Nov 16 '10 at 16:10
kubi
33.2k1886114
33.2k1886114
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
add a comment |
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
do you mean not using hooks at all? just replace "git pull" with, for example, "git uinttestspull"? that 's not exactly what I need
– sheepwalker
Nov 16 '10 at 16:22
1
1
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker: s/pull/push/, and use an alias to make it nice and short.
– Cascabel
Nov 16 '10 at 18:02
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
@sheepwalker Yeah, that's not exactly what you asked for, but like @calmh said, there's no pre-push hooks.
– kubi
Nov 16 '10 at 20:08
add a comment |
up vote
7
down vote
There isn't a hook for it, because a push isn't an operation that modifies your repository.
You can do the checks on the receiving side though, in the post-receive
hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.
add a comment |
up vote
7
down vote
There isn't a hook for it, because a push isn't an operation that modifies your repository.
You can do the checks on the receiving side though, in the post-receive
hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.
add a comment |
up vote
7
down vote
up vote
7
down vote
There isn't a hook for it, because a push isn't an operation that modifies your repository.
You can do the checks on the receiving side though, in the post-receive
hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.
There isn't a hook for it, because a push isn't an operation that modifies your repository.
You can do the checks on the receiving side though, in the post-receive
hook. That is where you would usually reject an incoming push. Running unit tests might be a little intensive to do in a hook, but that's up to you.
answered Nov 16 '10 at 16:37
Jakob Borg
16.6k54246
16.6k54246
add a comment |
add a comment |
up vote
5
down vote
For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.
Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.
Finally, you could run your tests in your pre-commit
hook but check for what branch is being committed to. Then you could have a, say, a production
branch that requires all tests pass before accepting a commit but your master
doesn't care. limerick_rake may be useful in that scenario.
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
add a comment |
up vote
5
down vote
For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.
Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.
Finally, you could run your tests in your pre-commit
hook but check for what branch is being committed to. Then you could have a, say, a production
branch that requires all tests pass before accepting a commit but your master
doesn't care. limerick_rake may be useful in that scenario.
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
add a comment |
up vote
5
down vote
up vote
5
down vote
For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.
Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.
Finally, you could run your tests in your pre-commit
hook but check for what branch is being committed to. Then you could have a, say, a production
branch that requires all tests pass before accepting a commit but your master
doesn't care. limerick_rake may be useful in that scenario.
For the record, there is a patch to Git 1.6 that adds a pre-push hook. I don't know whether it works against 1.7.
Rather than mess with that, you could run push script like @kubi recommended. You could also make it a Rake task instead so it's in your repo. ruby-git could help with this. If you check the target repo, you could run tests only when pushing to the production repo.
Finally, you could run your tests in your pre-commit
hook but check for what branch is being committed to. Then you could have a, say, a production
branch that requires all tests pass before accepting a commit but your master
doesn't care. limerick_rake may be useful in that scenario.
edited Nov 11 at 8:27
jchevali
1268
1268
answered Feb 17 '11 at 16:55
Turadg
5,96024144
5,96024144
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
add a comment |
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
thanks, actually I've already chosen the last variant (Finally, you could run your tests in your pre-commit hook..)
– sheepwalker
Mar 1 '11 at 15:56
add a comment |
up vote
0
down vote
The script linked by the highly-voted answer shows the parameters etc to the pre-push
hook ($1
is remote name, $2
URL) and how to access the commits (lines read
from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>
)
#!/bin/sh
# An example hook script to verify what is about to be pushed. Called by "git
# push" after it has checked the remote status, but before anything has been
# pushed. If this script exits with a non-zero status nothing will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
# <local ref> <local sha1> <remote ref> <remote sha1>
#
# This sample shows how to prevent push of commits where the log message starts
# with "WIP" (work in progress).
remote="$1"
url="$2"
z40=0000000000000000000000000000000000000000
while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi
# Check for WIP commit
commit=`git rev-list -n 1 --grep '^WIP' "$range"`
if [ -n "$commit" ]
then
echo >&2 "Found WIP commit in $local_ref, not pushing"
exit 1
fi
fi
done
exit 0
add a comment |
up vote
0
down vote
The script linked by the highly-voted answer shows the parameters etc to the pre-push
hook ($1
is remote name, $2
URL) and how to access the commits (lines read
from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>
)
#!/bin/sh
# An example hook script to verify what is about to be pushed. Called by "git
# push" after it has checked the remote status, but before anything has been
# pushed. If this script exits with a non-zero status nothing will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
# <local ref> <local sha1> <remote ref> <remote sha1>
#
# This sample shows how to prevent push of commits where the log message starts
# with "WIP" (work in progress).
remote="$1"
url="$2"
z40=0000000000000000000000000000000000000000
while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi
# Check for WIP commit
commit=`git rev-list -n 1 --grep '^WIP' "$range"`
if [ -n "$commit" ]
then
echo >&2 "Found WIP commit in $local_ref, not pushing"
exit 1
fi
fi
done
exit 0
add a comment |
up vote
0
down vote
up vote
0
down vote
The script linked by the highly-voted answer shows the parameters etc to the pre-push
hook ($1
is remote name, $2
URL) and how to access the commits (lines read
from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>
)
#!/bin/sh
# An example hook script to verify what is about to be pushed. Called by "git
# push" after it has checked the remote status, but before anything has been
# pushed. If this script exits with a non-zero status nothing will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
# <local ref> <local sha1> <remote ref> <remote sha1>
#
# This sample shows how to prevent push of commits where the log message starts
# with "WIP" (work in progress).
remote="$1"
url="$2"
z40=0000000000000000000000000000000000000000
while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi
# Check for WIP commit
commit=`git rev-list -n 1 --grep '^WIP' "$range"`
if [ -n "$commit" ]
then
echo >&2 "Found WIP commit in $local_ref, not pushing"
exit 1
fi
fi
done
exit 0
The script linked by the highly-voted answer shows the parameters etc to the pre-push
hook ($1
is remote name, $2
URL) and how to access the commits (lines read
from stdin have structure <local ref> <local sha1> <remote ref> <remote sha1>
)
#!/bin/sh
# An example hook script to verify what is about to be pushed. Called by "git
# push" after it has checked the remote status, but before anything has been
# pushed. If this script exits with a non-zero status nothing will be pushed.
#
# This hook is called with the following parameters:
#
# $1 -- Name of the remote to which the push is being done
# $2 -- URL to which the push is being done
#
# If pushing without using a named remote those arguments will be equal.
#
# Information about the commits which are being pushed is supplied as lines to
# the standard input in the form:
#
# <local ref> <local sha1> <remote ref> <remote sha1>
#
# This sample shows how to prevent push of commits where the log message starts
# with "WIP" (work in progress).
remote="$1"
url="$2"
z40=0000000000000000000000000000000000000000
while read local_ref local_sha remote_ref remote_sha
do
if [ "$local_sha" = $z40 ]
then
# Handle delete
:
else
if [ "$remote_sha" = $z40 ]
then
# New branch, examine all commits
range="$local_sha"
else
# Update to existing branch, examine new commits
range="$remote_sha..$local_sha"
fi
# Check for WIP commit
commit=`git rev-list -n 1 --grep '^WIP' "$range"`
if [ -n "$commit" ]
then
echo >&2 "Found WIP commit in $local_ref, not pushing"
exit 1
fi
fi
done
exit 0
answered Oct 1 '17 at 12:39
serv-inc
12.8k56484
12.8k56484
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f4196148%2fgit-pre-push-hooks%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
related: stackoverflow.com/questions/31681746
– tkruse
Jul 26 at 5:55