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