Unarchive and move

Hi,

No matter what I do, I cannot find a proper way to extract the content of a directory of a .zip file to a specific directory, without breaking idempotence.

Typically, wordpress-4.1.zip contains a “wordpress” directory which contains the files (most archives have a top directory actually). I would like to extract these files without the top directory (say wordpress/index.php to /var/www/mysite/index.php).

In a shell command, I could do a unzip && mv (with a few more tricks though), but that would trigger every single time. If I add a “creates”, it would not trigger if a specific file changes in the archive (something the “unarchive” module would properly deal with…). Well, you get it.

I’m sure I’m not the first one to encounter the issue. How do you deal with this?

Regards,
Warren.

What we do in similar cases is:

Extract to /whateverfolder/wordpresses/

Symlink /var/www/mysite to /whateverfolder/workpresses/wordpress

This way you can use the Ansible standard modules unarchive and file.

Hope this helps.

Lars

Perhaps you could just turn that zip into a package and use the yum/apt ansible module to handle the updates? Using something like fpm (https://github.com/jordansissel/fpm) could quite easily convert a zip into a package. Might make the process easier.

I think Lars answered your direct question well but I saw unarchive, idempotence, and zip mixed together here so I thought I should also make sure that you were using idempotence to mean, “unless the inputs change, the state will not change”. From looking at the unarchive code recently, I saw that what people sometimes mean by idempotence (that the ansible return value of change=False if no changes were performed) were not true for unarchiving zip files unless create= is specified… After some research it appeared that zip isn’t a standard enough format to easily tell whether the files in the archive match with the files on disk. It might be possible to partially implement (IIRC, using the python ZipFile module it looked possible to confirm file existence and checksums but modes and owner:group information had to be accessed as extended information that differed depending on the tool that/platform on which the zip file was created.)

Using zip with creates would solve that (but with the issue you noticed) or using tar as it doesn’t suffer from this problem.

-Toshio