In my .gitolite.rc file I have:
LOCAL_CODE => "$ENV{HOME}/.gitolite/local"
..then in ENABLE section of the same file I have enabled
repo-specific-hooks:
ENABLE => [
# COMMANDS
# These are the commands enabled by default
'help',
'desc',
'info',
...,
...,
...,
'repo-specific-hooks'
...,
...,
...
]
, now, on my local machine inside gitolite-admin folder I have:
gitolite-admin
...
...
└──local/
└── hooks/
├── common/
└── repo-specific/
└── message* <-- this one I want to call in a post-receive hook!
, and for some repo in my gitolite-admin conf file:
repo foo
RW+ = #all
option hook.post-receive = message <-- referencing script I want to call on post-receive
I did commit and push, from gitolite-admin and I can see that my message script got deployed where it should be on the server path ( that $ENV{HOME}/.gitolite/local ), with executable permsission set.
However, when I push to repo foo I don't get echoed message from my
message script, which simply is a bash script:
echo "hello from message"
exit 0
Why does that post-receive is not triggering?
Also if I understood well, there should be a symbolic link in that foo repo
called post-receive pointing to my message script, and there isn't one.
As confirmed by the OP, the per repo hook is only available from gitolite late 3.5 (Oct /2013), 3.6 (2014), not early 3.5.x (2013).
'repo-specific-hooks' was:
introduced in commit 62fb317 (gitolite 3.5.3, Oct 2013)
formerly tested in commit c0e36b3 (gitolite 3.6, May 2014)
debugged in commit b607f55 (gitolite 3.6.1, June 23d 2014)
So the very latest version of gitolite is needed here.
Related
RESUME
When I push from my local workspace to the target repo in GitLab on my remote VPS, I want GitLab run a script and ask a beta repo on the same VPS to git checkout and pull in order to check my changes.
Current configurations
Gitlab configurations
Suppose you already have a project in your admin area, you just need to get it's relative path
Admin area > Projects
Select your project
Get the path in the project profil (hashed for this case)
Create a new directory in this location called custom_hooks.
sudo su
cd /var/opt/gitlab/git-data/repositories/hashed/path/of/project
mkdir custom_hooks
Inside the new custom_hooks directory, create a file with a name matching the hook type. For a post-receive hook the file name should be post-receive with no extension.
cd custom_hooks
nano post-receive
Write the code to make the server hook function as expected. Hooks can be in any language. Ensure the ‘shebang’ at the top properly reflects the language type. In that case the script code used is :
#!/bin/sh
unset GIT_INDEX_FILE
cd /var/repo/beta.git && git checkout master && git up # --[see the note 2 below]
Make the hook file executable and make sure it’s owned by Git.
chmod +x post-receive
Note 1 :
You can find more informations about git hooks here : GitLab Documentation : Server hooks
VPS configurations
Create new alias with #RichardHansen recommandations
git config --global alias.up '!git remote update -p; git merge --ff-only #{u}'
Note 2 :
During my researches, I've found an interesting answer about git pull on the forum.
I've decided to follow that advice and I made an alias named git up.
What is important is that :
it works with all (non-ancient) versions of Git,
it fetches all upstream branches (not just the branch you're currently working on), and;
it cleans out old origin/* branches that no longer exist upstream.
You can find more informations about "In what cases could git pull be harmful ?" here :
Link to answer
Create a directory for git repos only and access it to process Hooks configurations
# Create a repo for the project in apache area
mkdir /var/www/beta
# Create the git repo only folder
cd /var
mkdir repo && cd repo
# Create git repo and init
mkdir beta.git && cd beta.git
git init --bare # --bare means that our folder will have no source files, just the version control.
# Add gitlab remote
git remote add gitlab
# Accessing hooks folder to create script
cd hooks
cat > pre-receive
# On the blank line, write this script then 'ctrl + d' to save and press enter to exit
#!/bin/sh
unset GIT_INDEX_FILE
git --work-tree=/var/www/beta --git-dir=/var/repo/beta.git checkout -f
# Make the file executable
chmod +x post-receive
Note 3 :
'git-dir' is the path to the git repository. With 'work-tree', we can define a different path to where the files will actually be transferred to.
The 'post-receive' hook will be looked into every time a push is completed and will set the path where the files will be transferred to /var/www/beta in that case.
Local Workspace configurations
# Create in your workspace a folder to hold the project
cd /path/to/workspace
mkdir project && cd project
# Initialize git and add gitlab remote
git init
git remote add gitlab ssh://user#mydomain.com/gitlab/path/of/project
# Create an index.html file and send the initial commit
nano index.html
# copy this into the file then 'ctrl + x' then 'y' then 'enter' to save
<html>
<head>
<title>Welcome to Beta domain!</title>
</head>
<body>
<h1>Success! The beta virtual host is working!</h1>
</body>
</html>
# prepare the changes and then send the commit
git status
git add index.html
git commit -m "chore: add index.html :tada: :rocket:"
git push gitlab master
EXPECTED RESULTS
The expected result of this process is that when the git push gitlab master is done, the hook inside the gitlab hashed directory of the project, run a script who make something like this :
# Access the beta.git directory
cd /var/repo/beta.git
# Run command for updating repo
git checkout master && git up
# If we access the beta folder in apache area we should see index.html
cd /var/www/beta
ls
--index.html
ACTUAL RESULTS
No result.
ERROR MESSAGES
No error messages.
REQUEST
How can I set up a process like this one ?
There is something in my process I did not take in consideration ?
One day I change a vim configuration from Github(https://github.com/ma6174/vim) on Linux(Visualbox Ubuntu), then some git orders doesn't work.e.g.:
git diff
diff-so fancy | less --tabs = 4 RFX: 1: diff-so fancy | less -- tabs = 4 RFX: diff-so:not found 4: No such file or directory
RFX: No such file or directory
Also when I input git branch, git log, it's doesn't work.Just give me something wrong.
But I can use git add ,git commit -m "", git push to push my file to the remote repository.I also can create a new branch, while can't check the information about dev or master.
Please tell me how to let git work normally.
We need to generate commit history file automatically when user commits code into git repository.
It can be done using Jenkins, Gitlab Webhooks and Jenkins Git Changelog plugin. Also, it can be created using below git command.
$ git log --pretty=format:'At %ci, %cN committed %h : %s' --decorate --graph >log.log
But, is there anyway we can generate commit history file using Gitlab CI/CD operations. The file can be saved in git repositry or local storage.
Sample Commit History File
* At 2018-11-16 18:02:21, kRiZ committed 1714a95 : Commit 4
* At 2018-11-15 16:06:06, kRiZ committed bab5c0c : Commit 3
* At 2018-11-14 18:05:09, kRiZ committed b3c9d86 : Commit 2
* At 2018-11-14 06:47:34, kRiZ committed 8e6ee30 : Add README.md
I'm sure there are multiple ways of doing this in GitLab. Here's one:
Create a .gitlab-ci.yaml file at the root of your repository. You can do this locally or using GitLab's web UI.
Paste this snippet into your .gitlab-ci.yaml file:
changelog:
image: docker:git
script:
- git log --pretty=format:'At %ci, %cN committed %h - %s' --decorate --graph >log.log
artifacts:
paths: [log.log]
Either commit and push locally or commit on GitLab's Web UI. The changelog job will be triggered.
After the job has finished successfully, your log.log file will be available as an artifact of the changelog job
Essentially, with this snippet you are setting up GitLab's CI/CD system to:
Use the Docker executor with a Docker image with git preinstalled
Define a changelog job that will run your git command
Define a log.log artifact that will be generated as part of the job and stored, so that you can download it afterwards.
I'd also recommend checking out the GitLab CI/CD quickstart
The library used by the Jenkins plugin also has a command line tool that can be used in anywhere:
npx git-changelog-command-line -std -tec "
# Changelog
Changelog for {{ownerName}} {{repoName}}.
{{#tags}}
## {{name}}
{{#issues}}
{{#hasIssue}}
{{#hasLink}}
### {{name}} [{{issue}}]({{link}}) {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
{{/hasLink}}
{{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
{{/hasLink}}
{{/hasIssue}}
{{^hasIssue}}
### {{name}}
{{/hasIssue}}
{{#commits}}
**{{{messageTitle}}}**
{{#messageBodyItems}}
* {{.}}
{{/messageBodyItems}}
[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*
{{/commits}}
{{/issues}}
{{/tags}}
"
My firm is setting up Gitolite on Linux and we would like to setup a backup for the server just in case of a crash on every commit to a 2nd Linux server.
How can we backup a Gitolite server on every commit to it? Is anyone doing this?
Another way to generate backups is to ask your post-receive hook to create a bundle (a bit like in this question)
!/bin/sh
git bundle create "/path/to/backup/$(basename "$PWD").bundle" --branches --tags
This is based on the fact that hook runs in a bare repo: see "how to get project path in hook script post-commit?".
The interest in bundle and git bundle is that is generates only one file, which is easier to manage/copy around.
And that fact acts as a (mostly read-only) repo, meaning you can clone from that file.
This would work:
git clone myrepo.bundle myrepo
See also:
"git bundle: bundle tags and heads",
"Backup a Local Git Repository", and
"Git with Dropbox".
First you should not worry too much about git backups. - Everyone who is working in your project will have a complete clone on his box. - Hence more than enough backups. ;)
But you want to have another official repository updated after each push. In this case probably the easiest way is writing a small server side hook, that runs after each push and itself pushes the changes to the second repository.
You probably want to use a post-receive hook. For details have a look at here or here.
Example:
#create repositories
git init a
git init --bare b
git init --bare c
#add the hook in "b"
echo -e '#!/usr/bin/bash\nread old new ref\ngit push ../c $ref' >>b/hooks/post-receive
chmod +x b/hooks/post-receive
#create a commit in "a"
cd a
echo foo >test
git add .
git commit -m testcommit
#push it to "b"
git push ../b master
#notice the "remote:..." output of the hook
#find the commit in "c"
cd ../c
git log
This creates three repositories. When you have a commit in a and push it to b the hook will push it to c, too.
I'm wondering is there a simple way to install hooks for certain repo using gitolite_admin.
Let's imagine i want to have post-update hook for repo awesome using gitolite_admin repo cloned to my workstation...
#conf/gitolite_conf
repo awesome
RW+ = deployer
contents of post-update:
#!/bin/sh
echo "Post receive-hook => updating Redmine repository"
sudo -u deployer perl -we '`cd /home/deployer/repo/awesome.git && git fetch -q --all`'
You could also look at "repo-specific environment variables"
A special form of the option syntax can be used to set repo-specific environment variables that are visible to gitolite triggers and any git hooks you may install.
For example, let's say you installed a post-update hook that initiates a CI job. By default, of course, this hook will be active for all gitolite-managed repos. However, you only want it to run for some specific repos, say r1, r2, and r4.
To do that, first add this to the gitolite.conf:
repo r1 r2 r4
option ENV.CI = 1
This creates an environment variable called GL_OPTION_CI with the value 1, before any trigger or hook is invoked.
Note: option names must start with ENV., followed by a sequence of characters composed of alphas, numbers, and the underscore character.
Now the hook running the CI job can easily decide what to do:
# exit if $GL_OPTION_CI is not set
[ -z $GL_OPTION_CI ] && exit
... rest of CI job code as before ...
Of course you can also do the opposite; i.e. decide that the listed repos should not run the CI job but all other repos should:
repo #all
option ENV.CI = 1
repo r1 r2 r4
option ENV.CI = ""
That feature is fairly recent (started in commit 999f9cd39, but in this case, completed in commit 63865a16 June 2013 for 3.5.2).
But even you don't have that version, there are other ways to do this using option variables, as the last part of that section explains.
Before this feature was added, you could still do this, by using the gitolite git-config command inside the hook code to test for options and configs set for the repo, like:
if gitolite git-config -q reponame gitolite-options.option-name
then
...
And you can use git config variables in the same way.
Or you can use group membership -- see the comments against function "in_group" in "Easy.pm" for details.
# in_group()
# return true if $ENV{GL_USER} is set and is in the given group
# shell equivalent
# if gitolite list-memberships $GL_USER | grep -x $GROUPNAME >/dev/null; then ...
In addition to sitaram's answer, the recent (August 29th, 2013) commit 62fb31755a formerly introduce repo specific hooks:
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)
You cannot specific a hook for gitolite-admin though.
And you hook is only one of the three following authorized hooks:
pre-receive
post-receive
post-update
That means you can:
store your repo specific hooks in your gitolite-admin/hooks/repo-specific/xx
declare those your in the gitolite-admin local options on the server.
First enable those hooks:
ENABLE => [
# allow repo-specific hooks to be added
# 'repo-specific-hooks',
Then declare the hooks on the server gitolite-admin repo:
gitolite git-config gitolite-options.hook=reponame hookname scriptname
(with a tab or \t between reponame hookname scriptname)
Original answer:
As mention in the gitolite man page on hooks
if you want to install a hook in only a few specific repositories, do it directly on the server.
(otherwise, you would be managing hooks for all git repos through gitolite-admin/common/hooks)
That being said, you could take advantage of VREF in gitolite V3.x, which are update hooks: those can be set for some repos and for some user, like any other rule.
You could then:
make your VREF script leave a 'flag' (a file) in the appropriate bare git repo being updated
make a common 'deploy' post-update hook, which would first look for that flag, and if found, deploy the repo (and remove the flag).
Again:
a post-update hook managed through gitolite-admin can only be common to all git repos (not what you want)
only VREFs can be associated to repos and users through gitolite.conf
The solution above tries to take those two facts into account to achieve what you are looking for: a deploy script running only for certain repos and managed through the gitolite.conf config file of the gitolite-admin repo.
Here are step by step instructions to complement #VonC's answer
gitolite hook for specific repository