gitolite hook for specific repository - hook

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!

Related

Git Update Files on Repo Change

I have a VPS running a Node.js / React app.
I want to update the files in the vps each time I push data to the git(hub).
I found out, using this answer, that I can add some hooks in git, executing commands on "post-receive".
What I didn't quite understand :
Why did he init another git ? Couldn't he have done this in the .git directory and create the hooks/post-receive file?
Why git checkout -f ? If the goal is to update local files, so nodemon / create-react-app restarts the server / app, why not execute a git pull instead ?
Is there a better way of doing this ?
In the recommended answer there, nobody is using GitHub and there is no other Git repository yet. So the answer to your question:
Couldn't he have done this in the .git directory and create the hooks/post-receive file?
is: No, there was no .git directory in the first place. The target machine had nothing at all, no Git repository, no working tree, etc. The git init --bare created the Git repository (the ".git directory").
The git checkout -f is a poor-man's / low-quality implementation of push to deploy. A receiving repository is normally "bare", and this one is no exception.
why not execute a git pull instead ?
That would require creating a third Git repository. That would have been an option.
"Better" is in the eye of the beholder. There are many ways of doing this, each with its own pluses and minuses. See also Deploy a project using Git push, which notes that since Git 2.3, receive.denyCurrentBranch = updateInstead is available; it was not available prior to 2015 (and in 2015, many people had older versions of Git installed).
Note further that if you're using GitHub as a hosting system, this changes a number of variables. The questions and answers you and I have linked here are aimed at those not using GitHub.

Migrate repos between instances of Gitlab

Due to my old installation of Gitlab being too difficult to upgrade (Thread on TKL support forums: http://www.turnkeylinux.org/forum/support/20120913/upgrading-gitlab ), I have downloaded the current TKL Gitlab distro, and followed Gitlabs standard upgrade path so that I now have a fully upgraded Gitlab 6.1 installation running with TKLBAM and all that good stuff. So far so good.
But, it turns out that our old version of gitlab does not give HTTP urls to repos, so that means that I can't use the "Import existing repository" function in Gitlab 6.1
I know that i can simply copy the old Git repositories from the old VM to the new one, but how can I make these repositories visible in Gitlab on the new VM?
I recently migrated from gitolite to gitlab and the official rake task gitlab:import:repos worked for me. I am using gitlab 6.1.0 (82f3446). Here is what I did:
rsync bare repos from gitolite to repositories/{group}/. Make sure to replace {repository} with the name of the gitolite repo, and change the hostname of your gitlab server.
rsync -rth --progress repositories/{repository}.git \
git#gitlab-server:/home/git/repositories/{group}/
Here, {group} is the name of the user group you want the repository to be added to. If you don't have any specific group, choose root as the group name.
Fix permissions – only necessary when the rsync user is not git:
sudo chown -R git:git repositories/{group}/
cd ~/gitlab
Run the rake task to import all new repositories:
bundle exec rake gitlab:import:repos RAILS_ENV=production
Now if you login as Administrator you will find the new project added.
For more information, refer to the "Import bare repositories into GitLab project instance" under http://{your-gitlab-server}/help/raketasks.
In your case, you can login to your old TKL system and rsync all bare repos to the new instance, followed by an import.
One option would be to:
Clone the old repo from gitlab onto a dev machine.
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
Push everything back to the new repo.
Remove the old repo from remote repos list.
To create a remote called newRepo, do: git remote add newRepo gitlab.localhost.com:User/newRepo.git (replace the url on the end with the one for your repo)
I did it practically the following way after reading ChrisA answer, which gave me a little headache about how to do it practically. The example copies a repo from github to gitlab, to make source and destination a little bit clearer.
Clone the old repo from github onto a dev machine (which creates a bare repo):
$ git clone --mirror git#github.com:me/myrepo.git
Create a blank repo on the new gitlab.
Add the new repo as a remote on the dev machine.
$ cd myrepo.git
$ git remote add newRepo git#gitlab.com:me/myrepo.git
Push everything back to the new repo.
$ git push --mirror newRepo
That's it.
This way it copied all branches and tags to the new destination.
You can now remove the cloned bare repo from your dev machine.
If your Gitlab is >= 8.9, then you can use export/import to migrate repos.
Since GitLab 13.8 (January 2021), you now have:
Migrate Groups directly between instances
A faster and easier way to migrate your GitLab Groups is on the way.
Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files.
In this release, we migrate only the Group object with basic fields.
We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.
See Documentation and Epic.

Bare Git repo cannot add files or commit files

So I have been plagued with this weird git problem that myself and a few other developers have not been able to solve. Here it is:
I created a bare repo for managing website changes using git on test server.
For this example the repo is here: /home/website/website.git
The website public root would be here: /home/website
I created the repo by doing this command: git init --bare
inside the git repo directory "website.git"
Next I have my local repo on a machine elsewhere. This is a standard git repo. I build the site get it ready to deploy. When its ready I push it to the bare repo. From my local repo.
There is a post-receive hook that checks the latest file tree out into the public root of the website. So when I change things on the local repo and test them in the localhost environment, once satisfied I can push them to the live server.
Here is the problem I face:
I can push fine. No issues. All works as expected. Code gets checked out to public root. Everybody is happy and goes on with their life.
BUT!!!:
The site is a CMS site. Users log in to it and upload things. Files get created on the public root of the website which is the GIT_WORK_TREE.
So NBD right?! I can just commit the files every now and then from the live bare repo and pull them back to my local environment like I have before. So I log into SSH on the server. Navigate to /home/website/website.git
Then run this command:
GIT_WORK_TREE=/home/website/ git add ../
I get this mess:
error: unable to create temporary sha1 filename ./objects/cb: No such file or directory
error: error_log: failed to insert into database
error: unable to index file error_log
fatal: adding files failed
I have done this before on other servers and it worked fine from what I remember. So I was like WTF, must be something strange on this server. I went to another server I have and replicated the EXACT same steps. Got the EXACT same problem. So now I fear I am loosing my sanity and maybe these previous git experiences are all made up in my head.... *Well, lets not go that far yet.... :)
Maybe somebody can help me out here. I have used git plenty and can't seem to crack this one.
Oh, some other maybe useful specs:
running CENTOS 6.2
I double checked all permissions. I even tried changing everything to 777 recursively just to make sure Im not loosing it somehow. Made sure all the files are owned by the correct user. chowned recursively. I also tried the standard solution to this problem which is described here: https://answers.atlassian.com/questions/132671/git-commit-fails-with-sourcetree-error-unable-to-create-temporary-sha1-filename-git-objects-d8-file-exists
That didnt work either. Not sure where to go from here.
PLEASE HELP ME!!!!
I feel like Linus is playing cruel tricks on me right now.
You have a bare git repository in /home/website/website.git which is inside of a git repository in /home/website? And then you try to trick the bare git repository into having a working tree using GIT_WORK_TREE?
Maybe it is worth understanding this setup but only if you intend to be a git developer. As you are a user focused on delivering website functionality, I suggest using a standard git setup.
Move the bare git repository elsewhere:
$ mkdir /home/repo
$ mv /home/website/website.git /home/repo/website.git
$ cd /home/website
$ git remote set-url origin /home/repo/website.git
I got the solution. This is it. I was running the above command from the git repo.
Turns out the command should be run from the work tree and altered to look like this:
GIT_WORK_TREE=/home/website/ git --git-dir="./website.git/" add ./

gitolite hook after git push doesn't work

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)

Gitolite hooks not propagating

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.

Resources