Come gestire l'abilitazione di nuovi moduli con Drush tramite makefile

8

Al lavoro ci stiamo muovendo per impostare i nostri nuovi siti in git e fare lo sviluppo locale. Finora ho creato un file drush make insieme a un profilo di installazione, e ho questo script tramite burattino in modo che quando un utente fa un nuovo clone di un repository scaricherà tutti i pacchetti ed eseguirà un'installazione di base del sito. Questo funziona bene.

Ora, la mia domanda è per quando devo usare un nuovo modulo per un sito. Ad esempio, costruiamo un nuovo modulo per il sito. Voglio che gli altri sviluppatori estraggano da git e installino automaticamente il nuovo modulo. L'aggiunta al file drush make causerà solo il download, e l'esecuzione di 'drush si' causerà la reinstallazione del sito, cancellando tutti i dati.

Qual è il modo migliore per raggiungere questo obiettivo?

modificare

Sento di non averlo spiegato correttamente. Sto cercando un modo per abilitare automaticamente i moduli in base alle voci del makefile in drush. L'idea è che l'utente verifichi un progetto, e poi avrò l'esecuzione di marionette 'drush make' e 'drush si' se non esiste alcun file settings.php. Quello che devo capire è quando la prossima volta che l'utente farà un pull e abbiamo aggiunto un nuovo modulo, come abilitarlo automaticamente tramite alcuni script. Se ho bisogno di scrivere qualcosa per analizzare il makefile ed eseguire 'drush en' manualmente, ma mi piacerebbe trovare qualcosa che è pre-costruito per farlo.

installing  version-control  drush 
— dragonmantank
fonte
"drush en" non è quello che vuoi per caso?
— Sam152,
Ho bisogno di un modo per automatizzarlo. 'drush en' può essere eseguito dalla CLI, ma quello che voglio è un modo per determinare quali moduli sono nuovi e abilitarli automaticamente.
— dragonmantank,
1
Il problema sarà che avere un modulo presente come set di file non significa che lo si desidera abilitato. Qualcuno deve prendere quella decisione. Ad esempio, se si scarica Views, si ottiene anche l'interfaccia utente di Views. Lo vuoi abilitato o no? È una decisione consapevole. Quindi hai bisogno di un elenco dei moduli e potrebbe anche essere in uno script.
— Alfred Armstrong,
Scusa, dimenticalo. In un certo senso capisco cosa intendi, anche se non sono sicuro del punto in cui tutto viene fatto attraverso make.
— Alfred Armstrong,
1
L'idea di @AlfredArmstrong era che dal momento che devo già curare il file make, per usarlo in qualche modo. Se desidero abilitare 'devel', ma non 'devel_generate', nel file make verrebbe inserito solo 'devel'. Se in seguito decidessi di abilitare 'devel_generate', lo aggiungerei al file make. Non voglio farlo solo in base a quali file sono disponibili specificamente per il motivo che hai citato, quindi devo controllarlo in qualche modo.
— dragonmantank,

Risposte:

4

Ho lavorato per un'azienda che aveva un grande flusso di sviluppo / stage / prod che cercava di automatizzare il più possibile. Tutto doveva essere fatto nel codice, tramite script utilizzando le funzionalità o gli hook di aggiornamento.

Fondamentalmente, quello che vuoi è avere 1 modulo personalizzato che esiste per contenere hook di aggiornamento. In questo modo, quando uno sviluppatore estrae un aggiornamento dalla base di codice, esegue l'aggiornamento del db e ciò può eseguire qualunque abilitazione / disabilitazione del modulo. Gli hook di aggiornamento non influiscono su una nuova installazione, poiché si presume che il modulo sia già aggiornato al momento dell'installazione e eseguirà solo gli aggiornamenti più recenti.

Riassumere:

  1. Continuare a utilizzare il profilo di installazione per eseguire le attività di installazione necessarie (abilitazione dei moduli, ecc.).
  2. Utilizza un modulo "aggiornamento" personalizzato che utilizza hook_update_NXXX () per abilitare / disabilitare i nuovi moduli e mantenere sincronizzate le attività amministrative del tuo sito.

Ecco un post che parla di un approccio simile e fornisce esempi di codice.

— coreyp_1
fonte
1

Questa è un'ottima domanda drush makeè comodo per scaricare i moduli. Non vogliamo contribuire al gonfiamento del modulo. Nel corso qui il caso è fatta non estendere makein questo modo. Forse Features è la soluzione migliore per gestire lo stato abilitato dal modulo del sito, così come altri aspetti della configurazione.

— Screenack
fonte
1

Valuta di modificare il flusso di lavoro.

Sembra che tu voglia fare un lavoro distribuito e "condividere" abilitando moduli e altri valori di configurazione ... in qualche modo.

Se ci pensate, anche Drupal "core" e Drupal.org non lo fanno. Il codice viene inviato ai moduli Core e della community eseguiti in un processo di generazione continua. Drupal.org e molti progetti usano Jenkins.

Per un'installazione di Jenkins orientata allo sviluppo di Drupal, utilizza anche Phing, vedere questo repository git: http://reload.github.io/jenkins-drupal-template/

Usando Jenkins, puoi inviare il codice al tuo repository Git master e far costruire il sito per un sito demo dal tuo profilo di installazione e dai tuoi Drush Makefile. Questo non risolve esattamente il tuo problema, ma fornisce 1 posizione in cui tutti spingi modifica (e) per aggiungere / abilitare / eliminare i moduli e speriamo che tutti non "rompano la build".

Supponendo che la build non sia interrotta, è sicuro apportare le modifiche al proprio sistema di sviluppo locale.

Jenkins + un server di gestione temporanea o di sviluppo è solo 1 pezzo di sviluppo.

Il flusso di lavoro locale può utilizzare i profili di installazione + i makefile. Valuta la possibilità di condividere i contenuti utilizzando i moduli personalizzati con Migrate se puoi permetterti il ​​tempo di generazione dei contenuti. Esempi di condivisione di contenuti con gli sviluppatori che utilizzano Migrate e l'utilizzo di Phing possono essere letti qui:

http://marzeelabs.org/blog/2014/03/17/coding-as-a-team-content-fixtures/ http://marzeelabs.org/blog/2014/03/03/coding-as-a- squadra-automazione-con-Phing /

Infine, guarda questo PDF in una sessione di Drupal Camp Ohio 2014 sull'integrazione continua e il lavoro con il tuo team:

— tenken
fonte
1

Per lo stesso scopo stiamo usando Master . Usa settings.php per fornire informazioni su quali siano i moduli master. Con un semplice comando drush master-executevengono abilitati tutti i moduli (e le relative dipendenze) mancanti e i moduli che non vengono più utilizzati vengono disabilitati.

Attualmente il modulo non legge le informazioni dal makefile, ma forse potrebbe essere un'opzione per una nuova versione.

— derhasi
fonte
0

È possibile abilitare i moduli manualmente tramite l' opzione Moduli o tramite il terminale utilizzando il comando drush

drush en -y modulename1 modulename2

e così via.

— Nitesh Sethia
fonte
Sto cercando un modo per automatizzare questo basato sui makefile, non solo su come abilitare un modulo manualmente.
— dragonmantank,
0

I moduli possono essere abilitati in 2 modi:

  1. o dal terminale usando il comando drush di:
    A. drush dl modulename- per scaricare prima il modulo
    B. drush en -y modulename- per abilitare il modulo

  2. Utilizzando l' opzione di menu Modulo e quindi abilitando il modulo dal numero di moduli visualizzati.

— Neetu Morwani
fonte
Sto cercando un modo per automatizzare questo basato sui makefile, non solo su come abilitare un modulo manualmente.
— dragonmantank,
Ci sono altri modi. module_enable()per esempio. O importando un database preparato.
— leymannx,
0

Voglio alcuni di questo che sono sicuro. La funzione make viene utilizzata per scaricare le diverse parti del sito: modulo, temi e progetto tramite git. Quando si annota il profilo di installazione, si scrivono nel file di informazioni i moduli dipendenti. Il problema è quando è necessario aggiungere un nuovo modulo per il profilo di installazione per il profilo esistente - ho ragione?

Per questo è necessario utilizzare hook_update_N quando N sta per l'aggiornamento del numero. L'hook viene utilizzato per i moduli che devono eseguire azioni quali: aggiornamento di schemi, aggiunta di variabili e utilizzo di siti e distribuzione, come OpenScholar, per abilitare i nuovi moduli scaricati sul sito live.

Probabilmente dovrai aggiungerlo nel modulo più generico e la funzione sarà simile a questa https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/openscholar/modules/os/os.install#L16

L'hook deve trovarsi nel file module.install. Se si utilizza l'interfaccia utente, è necessario visitare il sito www.site.com/update.php e se si utilizza drush è sufficiente utilizzare il comando drush updb.

— Roy Segall
fonte
0

A quanto ho capito, il file Drush .make scarica solo i progetti da drupal.org, se si desidera abilitare alcuni moduli, è possibile utilizzare un profilo di installazione ** (.install) **. Un profilo di installazione offre opzioni, quali moduli si desidera abilitare al momento dell'installazione.

Recentemente ho anche contribuito con una distribuzione con l'aiuto del file .make. Anche io ho condiviso l'intera esperienza di .make qui . So che questo non è correlato a quello che esattamente stai chiedendo, ma può aiutarti a capire esattamente cosa fa il file .make.

Quindi da tutto questo, quello che ho capito, usando il file .make non è possibile automatizzare l'abilitazione del modulo. Per fare questo è necessario seguire un altro approccio.

Spero che questo URL del forum ti possa aiutare. Automazione Drupal con scripting Bash e Drush .

Devi scrivere alcuni script bash in cui esattamente utilizzerai i comandi Drush.

drush en -y modulename
— Pushpinder Rana
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.