gitmirror
gitmirror copied to clipboard
add flags to select port to listen on, command to run through a shell
Should behave the same by default.
Let me know what you think and I'll update the README.
Thanks for reviewing it!
The port binding thing makes a lot of sense, but I'm not as sure about the shell thing. What are you hoping to accomplish here?
Also, /bin/sh is standard, so it'd be a better default if it does make sense. But it'd be at least another change if it's necessary.
The shell thing is to try to get around a limitation of flags. You can't pass without splitting something like:
-command='pull; git checkout mybranch'
The workaround is to revert to passing it to the shell of your choice in that case.
Kinda related to: http://stackoverflow.com/questions/20437336/how-to-execute-system-command-in-golang-with-unknown-arguments
Updated the PR with /bin/sh by default.
Let me know if you need more input in how I've used gitmirror in the past :godmode:
Can you accomplish your goal with a post-fetch script? I run a few hundred repos through, some of which have custom deploy-on-receive scripts and that usually does it, and in one installation, I've got a global post-receive that pushes the mirroring further down. It seems that this can take you a lot further, as I've done a lot of crazy stuff with this model and think changing the update command might be more limiting. I don't see what you can't do with the existing model.
I do want the binding change for sure. I can extract it if you'd like.
Thanks a lot for the feedback @dustin.
So in our case, we actually can't use a mirror as we need a working dir (the actual files in the repo), so a git clone works good enough for us.
We clone our repo through Chef, get Gitmirror set up with our fork.
When someones pushed to that repo (which has a bunch of YAML files), Github send the event to Gitmirror.
Gitmirror has in the post-fetch hook, a simple ruby script that goes through the YAML files and do other stuff.
If it's setup as a mirror, it's not going to work in that case.
That being said, if you think it's a bad idea, I'll keep the fork around. I just thought it would be fine based on the fact that it replicates the initial behavior of Gitmirror.
My golang skills are pretty limited as we have to pass:
%Q|/usr/bin/gitmirror -dir=#{node['gitmirror']['mirrors']['path']}/ -command="git reset origin/master --hard; git pull" -port=':#{node['gitmirror']['port']}'|
The -port ':4242' is kinda funky.
I'm not sure that's a particularly normal usage of gitmirror. Gitmirror itself is useful for maintaining the objects and triggering events. You can certainly have a checked out tree and trigger an update of it on that event.
Ideally, you just have the one replica instance that's receiving all the events from github or whatever and updating. Then for specific things where you want trees, you manage clones with trees from that shared repo (you can share objects with alternates or similar).
To accomplish that, you might have a post-fetch that looks like the following (totally untested):
#!/bin/sh
copath=/path/to/checkout
cd $copath || git clone `pwd` $copath
git pull && whatever
BTW, are you at gophercon?
Oh right I see your approach, set up the mirror then git clone it locally.
We tried this but I went with modifying Gitmirror (can't remember why).
Thanks for feedback, really appreciate you taking the time.
I'll leave you the port binding, because I think I'm doing it wrong with the : included :cactus: