Just wanted to add; this is almost exactly how we deploy PHP-based apps (with a bunch of bash scripts currently :/) at my current workplace, and having a built-in way to tidy up the process would be awesome.
On Monday, August 4, 2014 4:43:19 PM UTC-5, [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). > > 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 }}" ? > > 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) > > # 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? > > (sorry for al the questions, I'm trying to map your example to my actual > cases) > -- 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/74dcc8dc-a50e-4d74-bb7c-e22264a92490%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
