On Mon, Aug 4, 2014 at 5:43 PM, <[email protected]> wrote:
>
>
> Having a module that has a couple of modes, one might be via action plugin
>> to register a consistent symlink timestamp, and another via standard module
>> to make one "the one", and to clean out older timestamps, seems to make a
>> lot of sense.
>>
>> Maybe down the right track:
>>
>> # this would have to be a bypass host loop plugin or something to get a
>> consistent timestamp, but maybe we don't care
>> - deploy_prepare:
>> register: deploy_timestamp
>>
>
>> - deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/base
>> register: where_to
>>
>
> For the deploys we do with our galaxy role, a consistent timestamp is not
> an issue (small projects, single hosts). But for something in core, I would
> expect the ability to create a single timestamp for all hosts. I also
> really like the idea of a separate deploy_helper module that takes in this
> timestamp - but I remarked in my blogpost that a timestamp isn't really
> required (I gave 'commit hash' as an example folder name).
>
>
Yeah, good point, and may not be an issue anywhere really because of the
symlink, if there's good enough cleanup options.
Not requiring that seems like it would be a nice shortcut, provided that
the module could be called to register what the "latest" was if you didn't
pass too many arguments.
> Perhaps:
> - deploy_helper: *release_version*={{ deploy_timestamp.time }}
> base=/opt/base
> register: where_to
>
> Which allows for:
> - deploy_helper: release_version={{ my_own_versioning_implementation }}
> base=/opt/base
> register: where_to
>
>
>> # git checkout to where_to.path
>>
>
> I'm assuming "where_to.path" is the release-path-with-timestamp, and that
> this line is a placeholder for anything that goes on before the actual
> release is ready.
>
> Question: does the deploy_helper assume a folder structure?
> So in this case: would the where_to.path point to "/opt/base/releases/{{
> timestamp }}" ?
>
I think it would only assume a timestamp dir in base, but it could default
to make a subdir called "releases", sure.
I think as long as we document what it does we could make up a convention,
because it's going to change the way you deploy your app a little bit, and
you would not have to use unless you wanted...
>
> Our role currently places a file called "BUILD_UNFINISHED" in the
> where_to.path, and uses that file to remove failed builds (any folder
> containing it will die in the startup of the next deploy). That helped us
> out also, not having to identify where the "current" symlink is pointing
> to. Does that sound logical?
>
> Param: unfinished_file=BUILD_UNFINISHED (or yes/no, with a fixed value
> maybe)
>
This sounds pretty cool to me.
>
> # symlink latest dir into live and remove other symlinks
>> - deploy_helper: timestamp={{ deploy_timestamp.time }} base=/opt/base
>> live=/opt/live clean=yes
>>
>
> Again: does this assume a folder structure?
> So in this case, the symlink would become: /opt/live ->
> /opt/base/releases/{{ timestamp }} ?
> And any old releases in /opt/base/releases would be removed?
>
I think maybe you might need to pass a parameter to remove the other ones,
and it could be optional.
>
> (sorry for al the questions, I'm trying to map your example to my actual
> cases)
>
Yeah something like what you have, if not exactly, as a module seems really
really cool to me.
> --
> 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/992523ce-aa09-4c34-8137-2b730b258ccb%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/992523ce-aa09-4c34-8137-2b730b258ccb%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CA%2BnsWgzO%2B8kiNaX%3Daoz%3DfWpETve6zGTgcLCXfj0nV%3Dq30xeP5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
