È possibile annullare l'archiviazione di Ansible per scrivere i tempi di modifica delle cartelle statiche?

Question

Sto scrivendo un processo di compilazione per un'installazione di WordPress usando Ansible. Al momento non ha un sistema di compilazione a livello di applicazione e ho scelto Ansible in modo che possa integrarsi in modo pulito con gli script di build del server, così posso aprire un server funzionante con il semplice tocco di un pulsante.

La maggior parte dei miei plugin WordPress vengono installati con la funzione unarchive, che punta a versioni di plugin con versione sul server di installazione ufficiale di wordpress.org. Ho riscontrato un problema con uno solo di questi, che è sempre contrassegnato come "modificato" anche se i file sono esattamente gli stessi.

Dopo aver esaminato lo stato di ls -Rl prima e dopo, ho notato che questo plug-in (WordPress HTTPS) è l'unico ad utilizzare le sottodirectory interne e ad ogni decompressione, il tempo di modifica delle cartelle viene eseguito il bump.

Potrebbe essere utile sapere che si tratta di uno script di progetto, con uno connection di local. Immagino quindi che ciò significhi che SSH non viene utilizzato.

Ecco un frammento del mio playbook:

- 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 

Un modo hacky di fissare questo è quello di utilizzare ls -R prima e dopo, utilizzando le opzioni per includere le dimensioni dei file, ma non timestamp, e poi md5sum quell'uscita. Potrei quindi contrassegnarlo come modificato se c'è un cambiamento nel checksum. Funzionerebbe ma non è molto elegante (e vorrei farlo per tutti i plugin, per coerenza).

Un altro approccio è quello di abbandonare l'attività se esiste già un file di plug-in, ma ciò causerebbe problemi quando eseguo il bump del numero di versione del plug-in sulla copia più recente.

Così, idealmente, sto cercando un interruttore per presentare a unarchive per dire che voglio i tempi di modifica della cartella dal file zip, non dal runtime della cartella di gioco. È possibile?

---

Aggiornamento: un commentatore ha chiesto se il contenuto del file potrebbe essere stato modificato in alcun modo. Per determinare se essi hanno, ho scritto questo script, che crea un checksum per (1) tutti i contenuti di file e (2) tutti i timestamp di file/directory:

#!/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 

ho corso questo come parte del mio playbook (eseguirlo in isolamento usando i tag) e ha ricevuto questo:

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 

le linee di debug riflettono l'hash checksum del contenuto dei file (questo è identico) e quindi il checksum hash ls -Rl della struttura del file (questo è cambiato) . Questo è in linea con la mia precedente ricerca manuale che i checksum delle directory stanno cambiando.

Quindi, cosa posso fare dopo per rintracciare perché i tempi di modifica della cartella segnalano erroneamente questa operazione come modificata?

Answer 1

La mia soluzione è quella di modificare lo script checksum e per far sì che una caratteristica permanente del processo Ansible. Mi sembra un po 'hacky fare il mio checksum, quando Ansible dovrebbe farlo per me, ma funziona.

Nuove risposte che spiegano che sto facendo qualcosa di sbagliato, o che una nuova versione di Ansible risolve il problema, sarebbe molto gradita.

Se ottengo un momento, lo solleverò come un possibile errore con il team di Ansible. Tuttavia a volte mi chiedo del rapporto sforzo/ricompensa quando sollevo bug su un tracker occupato - ho già un oggetto in sospeso, è da un po 'che aspetto e ho scelto di aggirare anche questo.

Answer 2

Invece di sovrascrivere tutti i file ogni volta e trovare un modo per mantenere la stessa modifica datetime, è possibile che si desideri utilizzare l'opzione creates del modulo unarchive.

Come forse già sapete, questo dice ad Ansible che un file/cartella specifico verrà creato come risultato dell'attività.Pertanto, la prossima volta l'attività sarà non eseguirsi nuovamente se quel file/cartella esiste già.

Vedi http://docs.ansible.com/ansible/unarchive_module.html#options