Wordpress 是否可以使Ansible unarchive写入静态文件夹修改时间？

我正在使用Ansible编写WordPress安装的构建过程。它目前没有应用程序级的构建系统，我选择了Ansible，这样它就可以与服务器构建脚本干净地集成，这样我只需按一下按钮就可以启动一个工作的服务器

我的大多数WordPress插件都安装了

unarchive

功能，指向官方WordPress.org安装服务器上的版本化插件构建。我只遇到了其中一个问题，即它总是被标记为“已更改”，即使文件完全相同

检查了

ls-Rl

前后的状态后，我注意到这个插件（WordPress HTTPS）是唯一一个使用内部子目录的插件，每次解压缩时，文件夹的修改时间都会受到影响

知道这是一个项目构建脚本可能很有用，它具有

本地
的
连接。我猜这意味着SSH没有被使用

以下是我的剧本片段：

- name: Install the W3 Total Cache plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/w3-total-cache.0.9.4.1.zip
    dest=wp-content/plugins
    copy=no

- name: Install the WP DB Manager plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/wp-dbmanager.2.78.1.zip
    dest=wp-content/plugins
    copy=no

# @todo Since this has internal sub-folders, need to work out
# how to preserve timestamps of the original folders rather than
# re-writing them, which forces Ansible to record a change of
# server state.
- name: Install the WordPress HTTPS plugin
  unarchive: >
    src=https://downloads.wordpress.org/plugin/wordpress-https.3.3.6.zip
    dest=wp-content/plugins
    copy=no

解决这个问题的一种方法是在前后使用
ls-R
，使用选项包括文件大小，但不包括时间戳，然后使用
md5sum
输出。如果校验和发生变化，我可以将其标记为已更改。它可以工作，但不是很优雅（为了一致性，我希望对所有插件都这样做）

另一种方法是，如果插件文件已经存在，则放弃该任务，但当我将插件版本号添加到最新版本时，这会导致问题

因此，理想情况下，我正在寻找一个开关，以显示为
unarchive
，表示我希望文件夹修改时间来自zip文件，而不是来自playbook运行时。可能吗


更新：一位评论员询问文件内容是否可能发生了任何变化。为了确定它们是否有，我编写了这个脚本，它为（1）所有文件内容和（2）所有文件/目录时间戳创建一个校验和：

#!/bin/bash

# Save pwd and then change dir to root location
STARTDIR=`pwd`
cd `dirname $0`/../..

# Clear collation file
echo > /tmp/wp-checksum

# List all files recursively
find wp-content/plugins/wordpress-https/ -type f | while read file
do
    #echo $file
    cat $file >> /tmp/wp-checksum
done

# Get checksum of file contents
sha1sum /tmp/wp-checksum

# Get checksum of file sizes
ls -Rl wp-content/plugins/wordpress-https/ | sha1sum

# Go back to original dir
cd $STARTDIR

我将此作为我的剧本的一部分运行（使用标签隔离运行），并收到以下消息：

PLAY [Set this playbook to run locally] ****************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]

TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
    "checksum_before.stdout_lines": [
        "374fadc4df1578f78fd60b1be6758477c2c533fa  /tmp/wp-checksum", 
        "10d66f7bdbbdd3af531d1b11a3db3059a5868838  -"
    ]
}

TASK [jonblog : Install the WordPress HTTPS plugin] ***************
changed: [localhost]

TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]

TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
    "checksum_after.stdout_lines": [
        "374fadc4df1578f78fd60b1be6758477c2c533fa  /tmp/wp-checksum", 
        "719c9da94b525e723b1abe188ee9f5bbaf121f3f  -"
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=6    changed=3    unreachable=0    failed=0   

调试行反映文件内容的校验和散列（这是相同的），然后是文件结构的
ls-Rl
的校验和散列（这已更改）。这与我之前的手动发现一致，即目录校验和正在更改

那么，接下来我该怎么做才能追踪文件夹修改时间错误地将此操作标记为已更改？
与其每次都覆盖所有文件并找到保持相同修改日期时间的方法，不如使用
无存档模块的
creates
选项

您可能已经知道，这会告诉Ansible，任务将创建一个特定的文件/文件夹。因此，如果该文件/文件夹已经存在，则下次任务将不再运行

请参见
我的解决方案是修改校验和脚本，并使其成为Ansible进程的永久功能。当Ansible应该为我做校验和运算时，我自己做校验和运算感觉有点不舒服，但它是有效的

最受欢迎的回答是解释我做错了什么，或者Ansible的新版本解决了这个问题

如果我有时间，我将向Ansible团队提出这一可能的错误。然而，有时我确实想知道在繁忙的追踪器上引发bug时的努力/回报比率——我已经有一个未完成的项目，它已经等待了一段时间，我也选择了解决这个问题

更新（18个月后）
这个可移植的构建系统从未投入使用。我觉得我总是在做一些事情。最近，当我决定要把我的博客移到另一台服务器上时，我终于把它停靠了。这花了几个星期的时间（因为在真正的WordPress安装中需要考虑的事情多得惊人），但总的来说，我发现这个过程比使用编排工具要好得多。
是的，我考虑过了-很抱歉，我没有把倒数第二段说得更清楚，但这正是我所指的。在我看来，这种方法的问题在于，由于新版本的发布，当我将
wordpress https.3.3.6.zip
切换到
wordpress https.3.3.7.zip
时，任务将声称在现有安装上成功，而实际上它什么也没做。然而，我可以做的另一种方法是使用临时文件夹来组装应用程序，并删除
plugins
文件夹中的所有内容。当：False时，所有这些任务都可以标记为
changed\u，然后我
将它们同步到适当的位置，这会产生更改/未更改的输出。啊，不，这也不起作用-再次更改文件夹时间戳！呸。。。所以，谢谢你的上述建议，但你还有什么进一步的想法吗<代码>：-）
您绝对确定每次的内容都是相同的吗？如果您将所有内容相加，然后运行游戏并再次检查，会发生什么情况？如果Ansible正在覆盖一个具有相同内容的文件，我会非常惊讶，但可能在某个地方有一个bug。首先想到的是，WP安装在复制这些文件后正在修改其中一个。谢谢@ydaetskcoR。我相当肯定，是的-虽然我没有想到标记这个命令并单独运行它，所以我下一步会这么做。我相信每次运行时，归档文件的内容都是完全相同的，但目录中可能存在其他问题。但它不是WP-我没有在本手册中运行任何WP PHP安装代码。@ydaetskcoR：我已经完成了您建议的研究，发现文件确实是字节相同的-只是文件夹时间戳在更改。有什么新想法吗？同时，我将使用我的校验和脚本作为变化的度量，这将使我现在是幂等的-但它将是nic