Можно ли сделать Anarchable unarchive, чтобы написать статические времена изменения папок?

Я пишу процесс сборки для установки WordPress с использованием Ansible. На данный момент он не имеет системы сборки на уровне приложений, и я выбрал Ansible, чтобы он мог полностью интегрироваться со сценариями сборки сервера, поэтому я могу вызвать рабочий сервер одним нажатием кнопки.

Большинство моих плагинов WordPress устанавливаются с помощью функции unarchive, указывая на версии с плагинами версий на официальном сервере установки wordpress.org. Я столкнулся с проблемой только с одним из них, который заключается в том, что он всегда помечен как "измененный", хотя файлы точно такие же.

Изучив состояние ls -Rl до и после, я заметил, что этот плагин (WordPress HTTPS) является единственным, кто использует внутренние подкаталоги, а при каждой декомпрессии время изменения папок получает столкновение.

Может быть полезно знать, что это сборка проекта script, с connection of local. Я думаю, поэтому это означает, что 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 файла, а не из среды воспроизведения. Возможно ли это?


Обновление: комментатор спросил, может ли содержимое файла каким-либо образом измениться. Чтобы определить, имеют ли они, я написал этот script, который создает контрольную сумму для (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 файловой структуры (это изменилось). Это согласуется с моим предыдущим руководством по обнаружению изменений контрольных сумм каталога.

Итак, что я могу сделать, чтобы отслеживать, почему время изменения папки неверно помечено этой измененной?

Ответ 1

Мое решение - изменить контрольную сумму script и сделать ее постоянной функцией процесса Ansible. Он чувствует себя немного взломанным, чтобы делать мои собственные контрольные суммы, когда Ansible должен сделать это для меня, но он работает.

Новые ответы, которые объясняют, что я делаю что-то не так, или что новая версия Ansible исправляет проблему, была бы очень желанной.

Если я получу момент, я подниму это как возможную ошибку с командой Ansible. Тем не менее, я иногда задаюсь вопросом о соотношении усилий/вознаграждений при поднятии ошибок на занятом трекере - у меня уже есть один элемент, который он ждет, и я тоже решил обойти это.

Ответ 2

Вместо того чтобы переписывать все файлы каждый раз и находить способ сохранить одну и ту же дату и время изменения, вы можете использовать опцию creates для модуля unarchive.

Как вы уже знаете, это говорит Ansible, что в результате задачи будет создан определенный файл/папка. Таким образом, в следующий раз задача будет не запущена снова, если этот файл/папка уже существует.

См. http://docs.ansible.com/ansible/unarchive_module.html#options