Thanks for the reply. I've tried using the commit hash as argument for version, but it doesn't work: it has the same effect of version=master.
Il giorno sabato 7 giugno 2014 20:39:37 UTC+2, Dick Davies ha scritto: > > Try using something other than 'master' as a version, > > version=0d7a146a6eadd279218c1305d400d6058d17f26f > > for example. > > On 6 June 2014 21:27, parnigot <[email protected] <javascript:>> wrote: > > Hi all, > > > > I'm using ansible to manage a couple of django apps. In particular I'm > using > > the git module to get a clone of these apps in the production machines. > > If you don't know django, the configuration of the entire web > application is > > saved in a file (named settings.py) that is usually committed along all > the > > code. > > > > For a lot of reasons i keep two different settings.py files: > > > > The one committed in the git repo is the one containing the settings > using > > during development. > > For the production machine I have a different settings.py, not committed > and > > manage separately (it contains all the passwords for databases, API keys > for > > other service and other stuff that don't belong in the main repo). > > > > > > So, i run a playbook like this: > > > > - name: Clone the repository > > git: repo=... > > dest=/path/to/clone > > version=master > > force=yes > > notify: > > - django manage collectstatic > > - django manage south migrate > > - restart uWSGI > > > > - name: Upload production settings.py (this will overwrite the dev one > from > > the repo) > > template: src=settings.py.j2 > > dest=/path/to/clone/settings.py > > owner=root > > group=root > > mode=0644 > > > > That works fine but it does have a problem. > > If I run the playbook a second time the git task will always pull the > > repository overwriting the production settings.py uploaded the first > time, > > even when the clone is already up-to-date. > > Here's the verbose output for the task: > > > > TASK: [box | Clone the repository] ************************************ > > changed: [vagrant_home_server] => {"after": > > "0d7a146a6eadd279218c1305d400d6058d17f26f", "before": > > "0d7a146a6eadd279218c1305d400d6058d17f26f", "changed": true, "item": > > "/path/to/clone", "msg": "Local modifications exist"} > > > > You can see that the target repo is already up-to-date but the task has > > pulled the code overwriting the productions settings.py. This will also > > trigger the tasks under the notify, in particular the restart uWSGI one > that > > shouldn't be executed every time. > > > > > > So my question is: it is possible to keep the force=yes behavior, but > > pulling only when really needed? > > > > > > Best regards, > > EP > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ansible-project/a5308d07-d7c2-44aa-a40c-f76464c5e8f1%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b428d9cd-3abc-4362-a1b5-be5db1c9a5ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
