I search the method to copy files to "test" host when I launch the "git push" command.
git push ------- TO REPO --> REPO_SERVER
\
\_________ TO DIR --> Host_TEST
Git Version: 2.20.1
It sounds like you are trying to (re) invent CI/CD.
If you are using GitHub or GitLab as a remote server you can use Pipelines (or Actions in GitHub).
In there you can define (almost) anything you want to happen after a push, I am assuming your Host_TEST is accessible online.
In case you are running your own git server
You can implement "push to deploy" using the post-receive hook. Hooks are scripts that are placed inside .git/hooks and executed at a precise phase of a git command. you can find several example implementations in .git/hook. See here for more information: Setting up Push-to-Deploy with git
In case you don't have access to your own git server
You can use the pre-push script on your local machine, BUT THIS IS A BAD IDEA
This hooks is executed after you execute git push but before git actually pushes anything. If your script fails (i.e non-zero return code) it will not push.
Also, if your script manages to copy but then git fails to push you will end up testing code that's not in your repo.
If all this sound way too complicated
You can create a bash function that does both operations and add it to your .bashrc.
Here is an example:
push_copy() {
if git push
then
# Copy for command here: scp ...
else
echo "Failed..."
fi
}
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 ?
I'm desperately trying to prepare a correct environment for a new project. We plan to work locally with Xampp with my team and then push everything on a testing server, so I've started to learn git and its specificities.
When I try to push everything is ok, but then I want my server to automatically pull the updated files where it was cloned. So I created a post-update file which is like this.
#!/bin/bash
echo "Mise en production..."
cd /home/test/public_html/
unset GET_DIR
git fetch origin master
The problem is I get this error
remote: Mise en production...
remote: fatal: Not a git repository: '.'
Is there a better solution that would be efficient ?
Thanks everyone.
Your attempted solution works, but you have overlooked one detail.
When changing into /home/test/public_html/, you need to realize that this directory is not a Git repository and hence, you cannot fetch into it. To make this work, execute the following once.
$ cd /home/test/public_html
$ git init
$ git remote add origin [path/to/git/repo]
After that, you'll be able to git fetch and git pull in /home/test/public_html.
The [path/to/git/repo] should be a relative or absolute path to the directory that contains your repository. This is the directory that has directories branches, hooks, info, et cetera.
It seems you need that after the local repo changes are pushed to a testing server, then you also want the local changes are pushed to your server. So you can use post-update hook to do that:
In the testing server, edit the contents of hooks/post-update file as below:
#!/bin/sh
echo "Mise en production..."
branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
git push -u /path/for/your/server $branch
echo "push to my server "
I'm trying to use a remote trigger for (re)building in ci.gitlab. For explaining this, I made up this scenario:
2 repository, "lib" and "app1"
app1 will successfully build only if lib is included (solved simply by .gitlab-ci.yml)
I need to trigger the build of app1 (only for the master branch, in best-case) on commit (or merge request) of lib
I tried to figure it out using web hooks, but I wasn't able to find a url for ci.gitlab.com. Is this possible in a gitlab environment?
You can do this with newly added triggers functionality.
In your CI's project, find the section "Triggers". Add a trigger and use its token like this:
curl -X POST \
-F token=TOKEN \
https://ci.gitlab.com/api/v1/projects/{project_id}/refs/REF_NAME/trigger
(https://about.gitlab.com/2015/08/22/gitlab-7-14-released/)
Obsolete:
we have the same problem, and the way we solved it is by pushing and subsequently deleting a tag.
The assumption is that you manage the machine with Gitlab-CI runner. First, clone the main repository, app1 for you. And in lib's .gitlab-ci.yml add the steps:
- cd /path/to/app1_repository
- git pull
- git tag ci-trigger master
- git push origin ci-trigger
- git push --delete origin ci-trigger
- git tag -d ci-trigger
Make sure that you have the option Tag push events checked in your Gitlab Services settings for Gitlab-CI.
This solution has drawbacks:
Gitlab-CI runner must have write permissions to the repository, so it won't work for shared runners
git history will be bloated with all this tagging (especially Gitlab UI)
I opened an issue for this (https://gitlab.com/gitlab-org/gitlab-ci/issues/223) so let's hope they add this functionality to the API (http://doc.gitlab.com/ci/api/README.html).
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