I tried to search to find a solution.
but, I can't.
I installed gitolite. And it works well.
I can git clone on the local machine, and change gitolite-admin repo too.
But I want to use gitolite hooking.
followed this manual
http://sitaramc.github.com/gitolite/hooks.html
custom hooks
You can supply your own, custom, hook scripts if you wish. Install
gitolite as usual, then:
go to ~/.gitolite/hooks/common on the server and put your new hook
there now run "gl-setup" again You can use this procedure to install
new hooks as well as to update hooks that you had previously
installed.
So I tried to hook some basic shell script.
I put bash shell script on
~/.gitolite/hooks/common
and named it
update
update script file's owner is git, and excutable.
the shell script is like this..
#!/bin/bash
touch /tmp/$GL_REPO
and I execute
gl-setup mypubkey.pub
and then,
On my local git folder,
I modified some file, commit and push to gitolite server.
push works well. every file uploaded to the gitolite's repo.
but, hooking doesn't seems to occur. Nothing happened.
on the server's tmp directory, no file is created.
Did I forget something?
any comments plz...
You should realize that (from the "using hooks" page you mention in your question=:
The update hook is used in all repos and is critical to gitolite's access control
In other words, you cannot directly use an "update" script.
You must use the "hook chaining" feature of gitolite, in order to call your own update hook after the one of gitolite:
To run your own 'update' hook, just put it in a file called update.secondary and install it as a hook.
Gitolite's update hook will automatically chain to it, taking care to pass it the same 3 arguments the original update hook received from git.
In the end, the OP Jinbom Heo, rather than using "gitolite hook chaining", went with another hook:
I put post-receive file in /var/gitolite/hooks/common/ folder. And it works.
The doc "Where do I put my hooks" suggest rather to put those under the "user" location (~/.gitolite/hooks/common):
But the system location works too.
( /var/gitolite/hooks/common/ means, by the way, the OP chose the root method installation or the package one, with the default paths /usr/local/bin, /var/gitolite/conf, /var/gitolite/hooks)
Related
I'm exporting a file in one folder and moving it to production without performing an change, using this command:
svn export --username user --password passwd --non-interactive --force svn://svnserver.com/trunk/patch/115/sql/TestFile.sql
After the movement I would like to add a comment/tag that file was moved successfully. For this, I tried the commands below but they didn't work:
> svn commit -m " Test" TestFile.sql
svn: '/home//SVNTEST/1' is not a working copy
> svn commit -m "Test" svn://svnserver.com/trunk/patch/115/sql/TestFile.sql
svn: Must give local path (not URL) as the target of a commit
Will it be possible if yes how to do so?
To summarize, you're copying a file from the repository to your local machine, then you want to somehow indicate in the repository that this action happened.
Without knowing more about your setup, I think creating a tag is probably the most straightforward way to do this. Use this command:
svn copy svn://svnserver.com/trunk/ svn://svnserver.com/tags/115 -m "Test"
Use whatever unique key for the tag name (here I used '115' since it seemed like that was a patch identifier).
Let's discuss why the commands you tried did not work.
Since you're exporting rather than checking out the file, you don't have a working copy. Exporting is basically equivalent to downloading a file from an HTTP or FTP server; there are no strings attached.
Now, the subcommand commit requires a working copy (in order to know where in the repository to put your local changes), which explains why in the first command you tried the error indicated you aren't in a working copy. The second command errored because you (I think) are trying to tell SVN the remote location to upload your local TestFile.sql, which is not a valid use-case for the commit subcommand.
My suggestion creates a tag, but does so entirely on the server which means you don't need a working copy.
There is a server running and has a git instance on it. I want a script to run everytime a user does git push to the server. I want my script to be executed then git push to continue.
Any work arounds?
You've tagged this GitHub so I'm assuming that you are referring to public GitHub and not GitHub enterprise.
You cannot run a script "server-side" on GitHub's servers because that would obviously be a massive vulnerability but you can set up a web hook to trigger a script on another server.
Basically whenever someone does a push, a specific URL will be sent data about the push. You can then trigger a script from this. For more information on web hooks, see the GitHub API docs.
I am not sure If you want a scipt to run prior to push or after. So here is my answer for pre-push. But if you want post-push (i.e after push) you have to change the pre-push hooks accordingly to check if pushed successfully and then you can do post push thing.
As suggested by #Travis, git hooks is the one that you are looking for. So to execute a script pre-push, you have to do is to create a pre-push file in the .git/hooks. So in this case put your bunch of code in the pre-post script file .git/hooks/pre-push and save it. Then make it executable by chmod +x .git/hooks/pre-push. After you done with this successfully you will be able to see the script gets executed each time you do run push command.
PS: Please note that I haven't tested this whole but expected to work in this way.
In Short, assuming you(Linux user) are in the project directory
vim .git/hooks/pre-push # then add your code and save the file
# Also put the shebang on top to identify the interpreter
chmod +x .git/hooks/pre-push # make it executable
You should look into git hooks:
8.3 Customizing Git - Git Hooks
and, another site regarding this technology:
githooks.com
Recently I migrated from opensuse to centos and after that GIT has started to ignore my custom commit-msg hook. It simply doesn't execute it. (I checked it by add small piece of code to "add_ChangeId" function )
Hook generates Change-Id hash for every commit
GIT version: 1.8.1.2
File is located in following location: .git/hooks/
For debugging purposes I even have set 0777 permissions to the whole .git directory
Here is the full text of commit-msg file - http://pastebin.com/zmYNi0ED
timoras you are gold. Then I tried to execute script using sh .git/hooks/scriptname it worked, but when tried to call it using .git/hooks/scriptname and shell returned that I haven't permissions to execute it.
After that I looked at fstab, and found out that have forgot to add exec flag to the partition where this file was located.
Now everything works.
One more time thanks timoras!
I don't understand how do I create a post-receive hook for a specific repository in gitolite (non-root install)
My bare repository contains a website that should copy the working directory to the docRoot
(GIT_WORK_TREE=/path/htdocs git checkout -f) on update
Before gitolite, I would just update the hook for the specific repository.
Gitolite documentation mentions that all hooks should be at hooks/common so I don't understand how it works.
What should be the name of hooks, where it should be located and how it's structure should be changed (if it should)?
Update July 2013: what follows is for gitolite V2 (or 'g2'), which was the version used by the OP at the time (November 2011).
Update August 2013, with the latest gitolite 3.x:
You now have official specific repo hook:
it's basically just creating a symlink in <repo.git>/hooks pointing to some file inside $rc{LOCAL_CODE}/hooks/repo-specific (except the gitolite-admin repo)
All hooks in gitolite/hooks/common are replicated in all repositories managed by Gitolite, as detailed in the hook propagation documentation.
That means your hook script must take specific action depending on the repo which execute said hook.
You can either use the $GL_REPO variable (which gitolite set and pass to all its scripts for any git command it receives).
Or you can use some git configuration registered on the gitolite server, like the mirroring hook does. See the post-receive.mirrorpush hook.
The OP Eyal R adds in the comments:
But I still don't understand how it is done (I understand that $GL_REPO is used to determine which repo I am updating but I'm missing the practical part).
I have created a file called post-receive.test with echo "test", put it in $HOME/gitolite/hooks/common, ran gl-setup, ran push from workstation - nothing happens (no "test" output)
To which I replied:
The hook should appear in the hook directory of your repo on the gitolite server as a link, linking back to the .gitolite/common/hook. Note that it should be in $HOME/.gitolite/common/hook, not /gitolite.
The OP confirms the missing dot was the issue.
The process to add an hook is detailed in Hook propagation in gitolite, and their usage in "Using Hooks".
This is a fairly common need for someone using gitolite, and appears to be a little difficult to tie up loose ends when being not a very advanced user (at leas it was for me).
Following stackoverflow's and gitolite's links back and forth can be a little confusing. These are my conclusions and the path I followed to be able to achieve this.
As #VonC mentioned creating repository specific hooks is already possible since version 3.5.3.1 (github link)
Update/Upgrade Gitolite
The first thing you should do is update your gitolite repo. So ssh into your server that is hosting gitolite and move to the location where gitolite is installed (usually /home/git/gitolite) as the git user (usually git)
Example:
$ ssh myusername#devserver.com
$ sudo su - git
$ pwd
/home/git
$ cd gitolite
Then we have to upgrade gitolite. To do so, first we need to update the gitolite repository
$ git pull
Then we have to repeat the install command (make sure you use the same arguments as before)
$ ./install
And finally run the setup again.
$ gitolite setup
If that doesn't work, you probably haven't set up gitolite executable in your PATH, so you could do something like this:
$ src/gitolite setup
Gitolite Settings (The "RC" file)
This was one of the parts that confused me the most, but it ended up it was pretty straight forward.
The famous "rc" file is located at git's home directory /home/git/.gitolite.rc. There make sure you have a variable called LOCAL_CODE, you should see something like this on that file, if not, add it.
LOCAL_CODE => "$ENV{HOME}/.gitolite/local"
And in the "commands an feature to enable" section you should make sure that repo-specific-hooks is available, if not, add it.
ENABLE => [
# COMMANDS
# These are the commands enabled by default
'help',
'desc',
'info',
...,
...,
...,
'repo-specific-hooks'
...,
...,
...
]
Here is the link to the documentation
Writing Repository Specific Hooks
Finally, in your local gitolite-admin repository create the following directories hooks/repo-specific under the directory you just set in the LOCAL_CODE variable, for example:
gitolite_admin/local/hooks/repo-specific
After that you can actually add your hooks scripts to that location and manage them through the gitolite conf file as stated in the documentation. Make sure the scripts are executable.
repo foo
RW+ = #all
option hook.post-receive = deploy
Again, I hope this helps some of you guys.
Cheers!
I've been through the extensive gitolite documentation over and over again. This is my configuration :
Git user running gitolite, while I installed Gitolite as another user, which had root privileges. I installed using the gl-system-install method.
Now, I see two copies of hooks/common directory /usr/local/share/gitolite/hooks/common and /home/git/.gitolite/ (and I intend to work with the first one for system wide implementation)
The gitolite-source is located at /home/user/gitolite-source
I've put in some dummy hooks in the /home/user/gitolite-source/hooks/common/ directory (post-udpate, post-update.secondary, post-receive and post-commit). All of these have exec bit set.
If I edit the update hook in this directory and re-run the setup again, the newer update hook (in existing repos) is sym-linked to the update hook in /usr/local/share/gitolite/hooks/common.
But even though any newer hooks in the source/hooks/common directory are copied over to both the hook locations, newer sym-links do not appear in my existing repos.
In short : gitolite copies its own hooks, but neglects mine.
Any idea why?
I figured out the answer on my own.
I was re-running the gl-system-setup over and over again in hopes of making those sym links created for me under each repository, while it was the gl-setup that did it.
But re-running gl-setup did not work either. (It gave strange parse errors). So I decided to just remove all the gitolite-hooked sentinel files, and push an update to the gitolite-admin repo, which copies hooks over if it does not find the gitolite-hooked file.