1

We have two servers - ServerA (bare repo) and ServerB (hosted project folder). Every time a developer pushes local changes to ServerA they should be automatically pushed to ServerB.

What I have tried so far: I created a post-receive script in bare_repo/hooks/. The script is:

#!/bin/bash
while read oldrev newrev ref
do
    if [[ $ref =~ .*/master$ ]];
    then
        echo "Master ref received.  Deploying master branch to production..."
        git --work-tree=remoteaddress --git-dir=/volume1/_Repos/test.git checkout -f
    else
        echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
    fi
done

Where remoteaddress is something like IPServerB:/path/to/hosted_project_folder.

My entire approach:

hosted_project_folder already existed. Then on ServerA:

git clone --mirror IPServerB:/path/to/hosted_project_folder
git fetch --all

Add post-receive script in hooks.

On Client:

git clone IPServerA:/path/to/bare_repo

Add changes at Client and push it to ServerA:

git add -A
git commit -m "add something"
git push origin master

Where origin is IPServerA:path/to/bare_repo

At this point I get an error:

remote: fatal: Invalid path '/volume1/_Repos/test.git/IPServerB:C:': No such file or directory

However, if we use one server for bare repo and hosted project folder then it works.

edu
  • 11
  • 3
  • For working tree files, Git uses the system-provided operations (`mkdir`, `rmdir`, `open`, `symlink`, etc., calls from C code). Whatever they allow, Git allows; whatever they don't, Git doesn't. Windows does allow mounting remote file systems, but with various restrictions that may be problematic (or may not—I'm no Windows expert). It's generally not wise to *use* such extensions because they tend not to provide the POSIX file semantics that Git requires. – torek Aug 30 '22 at 09:57
  • In short, "don't do that": do deployment with something that actually does deployment, rather than trying to whack Git into acting as a deployment system. – torek Aug 30 '22 at 09:58
  • @edu : I'm a bit lost between your IPs. Which one is the server with the bare repo ? `serverA` ? – LeGEC Aug 30 '22 at 10:22
  • @LeGEC yes, serverA is the server with bare repos – edu Aug 30 '22 at 10:40
  • @torek so is it not a good practice, to synchronize the bare repo with our deployment repo? Should we do it manually? – edu Aug 30 '22 at 10:54
  • What I'm saying is that Git itself makes a lousy deployment system. It's an OK version control system, but it was never intended to be a deployment system, and when pressed into service to *act* as one, it performs badly. Use Git as a VCS, not as a deployment mechanism. Use some other software to deploy the commit stored in Git. – torek Aug 30 '22 at 10:56

1 Answers1

0

A few points to fix :

a. appart from git push and git fetch, git works 100% locally.

git --work-tree=someip:somewhere doesn't work -- git expects its worktree to be something that is mounted on the local filesystem -- you should have ServerA push to ServerB, or ServerB fetch from ServerA.

Then you take extra actions to actually deploy on ServerB.

b. the post-receive script will be run synchronously : git push from your client will trigger a call to post-receive, and wait for the script to complete.

So you probably want to just trigger a deployment, but not wait for it to complete. e.g :

  • trigger a deployment through http : curl https://serverB/myproject/trigger _deployement

  • or some job (a cron job ? a daemon which watches the modifications in a directory ?) that expects a change in a file : ssh serverB touch trigger_dir/trigger_file

  • or start a script asynchronously on ServerA : nohup deploy.sh "$hash" >> /tmp/deploy.log 2>&1

  • or ...

LeGEC
  • 46,477
  • 5
  • 57
  • 104