1

Good morning everyone!

On my daily job, we are using NGINX+uWSGI+MongoDB as Python Application container. For versionning and collaborative developpement we are using GIT install on each developer computer and a central GIT repository for delivery purpose.

Everything is running well and smoothly, BUT there is one minor issue.

Until now, when we want to deliver a new version of our internal softwares, all developers merge their changes and then a choosen one (usually the project manager) push the final product into the "branch master" repository on our central GIT Server.

Once this push is made, a script which is constently looking on GIT retrieve the new version and push it on our uWSGI server which then load the new version for all new connections.

Now, we are wondering how to be able to push on GIT server and that uWSGI directly load and servs its webapps from this GIT server.

Is there anybody which already have a similar solution or a uWSGI configuration to do so?

Dr I
  • 955
  • 17
  • 33

2 Answers2

2

A trick i use with my company website (it is generated from a github repository) is adding those options to uWSGI:

; reload the server everytime the repository is updated
touch-reload = .git/index
; every minute pull from the repository
cron = -1 -1 -1 -1 -1 git pull
roberto
  • 1,827
  • 12
  • 8
  • Indeed, there is as you noticed it a way to know that files has been updated, but I'm rather looking for a way to said uWSGI to access file through GIT APIs directly, not to perform a script to update my filesytem directory. – Dr I Sep 10 '13 at 10:24
1

your server-based git-repo is nothing you'd work with; you'll always depend on a local repo-clone, derived from that central git-repo (IMHO). what you can do to get rid of ugly cronjobs: use git's pre/post-receive-hook on your git-server:

In addition to the client-side hooks, you can use a couple of important server-side hooks as a system administrator to enforce nearly any kind of policy for your project. These scripts run before and after pushes to the server. The pre hooks can exit non-zero at any time to reject the push as well as print an error message back to the client; you can set up a push policy that’s as complex as you wish.

there is also an informative stackoverflow-discussion about git-post-receive-hook for website-staging; esp. check out the first link from the top-answer git-website-howto

Community
  • 1
that guy from over there
  • 1,355
  • 10
  • 11
  • yeah! Many thanks, THIS is the elegant way that I was looking for! So, if I correctly understand this feature, it's able to perform actions (scripts/etc) before and after a push from my client on a GIT central point isn't it? Thank you so much for this doc! I'll read it carefully. – Dr I Sep 11 '13 at 07:27
  • yes, thats it. the hooks are barely just shellscripts that can include links to other scripts. this is how we do deployments to test-servers, no humans involved, no ugly scripts or wasted resources with cronjobs :) – that guy from over there Sep 11 '13 at 07:51
  • Using this wonderfull new keyword, I've perform some search and found usefull methods like the one use by GitHUB to send a JSON at a specific URL set by users and where the WebServer parse the JSON and do the checkout etc. Anyway, thank you very much, this is a wonderfull feature of GIT and I just now regret to don't have seen it before :D – Dr I Sep 11 '13 at 08:48