The issue is that if you have a play that runs across 50 hosts and you
delegate 50 steps to localhost they will all use a different timestamp
because it was told to register 50 different versions of that variable.
-e to Ansible is the --extra-vars flag.
ansible-playbook foo.yml -e "version=1.2.3.4"
etc
The alternative would be to do the timestamp step only once:
- hosts: localhost
tasks:
- shell: whatever
register: time
- hosts: webservers
roles:
- do real things here
and then where needed:
{{ hostvars["localhost"]["time"] }}
and that way the timestamp would be consistent amongst hosts.
On Mon, Dec 30, 2013 at 5:41 PM, Stan Lemon <[email protected]> wrote:
> I'd actually done this with my local copy over the weekend and tied it
> into the deploy.yml that gets included. I'm still very much iterating, but
> ansible let me get atomic deploys up and running over the weekend for three
> deploys (two apps, one with a staging branch) on a super-crusty-old server
> that is due to be rebuilt next month.
>
> "-e" flag, for git? Not sure I'm familiar with this... maybe I
> misunderstand?
>
> I may not understand how this works, so please correct me if this is the
> case - but I was exporting the timestamp on the local (aka deployment)
> machine and register that as a variable to be used on the node(s) when
> deploying. I considered using a git sha1 for the build too - but then my
> "keepers" pruning won't work reliably. I don't have strict build tag
> numbers (yet) from my CI system, but that would also be another option.
>
>
> On Sunday, December 29, 2013 7:25:28 PM UTC-5, Michael DeHaan wrote:
>
>> I'd maybe consider passing in what version (git tag, etc?) you are
>> deploying with "-e" and then you could probably save the "timestamp" step
>> too.
>>
>> Note that the timestamp might be different between hosts, so passing it
>> in seems better to me, that way your directory names would be consistent.
>>
>> (Or otherwise, use the hostvars trick to get the variable from a very
>> specific host)
>>
>>
>>
>> On Sun, Dec 29, 2013 at 10:52 AM, Brian Coca <[email protected]> wrote:
>>
>>> nothing broken I can see, but a few things:
>>>
>>> - local_action: and delegate_to: 127.0.0.1 mean the same thing you can
>>> remove one, don't need both.
>>>
>>> - sudo: false is the default, since you don't set it to true at the play
>>> level you should only need to set it to true for tasks that require it.
>>>
>>> - git archive can create a tarball that already doesn't have special
>>> files/dirs
>>>
>>>
>>>
>>> --
>>> Brian Coca
>>> Stultorum infinitus est numerus
>>> 011000010111001001100101011011100010011101110100001000000111
>>> 100101101111011101010010000001110011011011010110000101110010
>>> 0111010000100001
>>> Pedo mellon a minno
>>>
>>> --
>>> 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].
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Michael DeHaan <[email protected]>
>>
>> CTO, AnsibleWorks, Inc.
>> http://www.ansibleworks.com/
>>
>> --
> 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].
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Michael DeHaan <[email protected]>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/
--
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].
For more options, visit https://groups.google.com/groups/opt_out.
