Cómo manejar la habilitación de nuevos módulos con Drush a través de un archivo MAKE

8

En el trabajo, nos estamos moviendo para configurar nuestros nuevos sitios en git y hacer desarrollo local. Hasta ahora, he creado un archivo drush make junto con un perfil de instalación, y lo he escrito mediante una marioneta para que cuando un usuario haga un clon nuevo de un repositorio, descargue todos los paquetes y ejecute una instalación básica del sitio. Esto funciona bien

Ahora, mi pregunta es cuando necesito usar un nuevo módulo para un sitio. Por ejemplo, creamos un nuevo módulo para el sitio. Quiero que los otros desarrolladores saquen de git y tengan el nuevo módulo instalado automáticamente. Agregarlo al archivo de creación de drush solo hará que se descargue, y ejecutar 'drush si' hará que el sitio se reinstale, borrando todos los datos.

¿Cuál es la mejor manera de lograr esto?

Editar

Siento que no he explicado esto correctamente. Estoy buscando una manera de habilitar automáticamente los módulos basados ​​en las entradas del archivo MAKE en drush. La idea es que el usuario revise un proyecto, y luego haré que Puppet ejecute 'drush make' y 'drush si' si no existe el archivo settings.php. Lo que necesito averiguar es cuándo la próxima vez que el usuario haga un pull y agreguemos un nuevo módulo, cómo habilitarlo automáticamente a través de algún script. Si lo necesito, escribiré algo para analizar el archivo MAKE y ejecutaré 'drush en' manualmente, pero me gustaría encontrar algo que esté preconstruido para hacer esto.

installing  version-control  drush 
— dragonmantank
fuente
"drush en" no es lo que quieres quizás?
— Sam152
Necesito una forma de automatizarlo. 'drush en' se puede ejecutar desde la CLI, pero lo que quiero es una forma de determinar qué módulos son nuevos y habilitarlos automáticamente.
— dragonmantank
1
El problema será que tener un módulo presente como un conjunto de archivos no significa que desee habilitarlo. Alguien tiene que tomar esa decisión. Por ejemplo, si descarga Vistas, también obtiene la IU de Vistas. ¿Quieres eso habilitado o no? Es una decisión consciente. Por lo tanto, necesita una lista de los módulos y también podría estar en un script.
— Alfred Armstrong
Lo siento, olvídalo. De alguna manera entiendo lo que quieres decir, aunque no estoy seguro del punto de que todo se haga a través de make.
— Alfred Armstrong
1
@AlfredArmstrong, la idea era que, dado que ya tenía que seleccionar el archivo de creación, usarlo de alguna manera. Si quiero habilitar 'devel', pero no 'devel_generate', entonces solo 'devel' estaría en el archivo make. Si más tarde decidí tener habilitado 'devel_generate', lo agregaría al archivo de creación. No quiero hacerlo solo en función de qué archivos están disponibles específicamente por la razón que mencionó, por lo que necesito controlar eso de alguna manera.
— dragonmantank

Respuestas:

4

Trabajé para una empresa que tenía un gran flujo de desarrollo / etapa / producción que intentaba automatizar lo más posible. Todo tenía que hacerse en código, con secuencias de comandos utilizando características o ganchos de actualización.

Básicamente, lo que desea es tener 1 módulo personalizado que exista para contener enlaces de actualización. De esta manera, cuando un desarrollador extrae una actualización de la base de código, ejecuta la actualización de db, y eso puede realizar cualquier habilitación / deshabilitación del módulo que deba ocurrir. Los enlaces de actualización no afectan a una nueva instalación, porque se supone que el módulo ya está actualizado cuando está instalado, y solo ejecutará actualizaciones más recientes.

Para resumir:

  1. Continúe usando su perfil de instalación para realizar las tareas de instalación necesarias (habilitar módulos, etc.).
  2. Use un módulo de "actualización" personalizado que use hook_update_NXXX () para habilitar / deshabilitar nuevos módulos y, de lo contrario, mantener sincronizadas las tareas administrativas de su sitio.

Aquí hay una publicación que habla sobre un enfoque similar y proporciona ejemplos de código.

— coreyp_1
fuente
1

Esta es una gran pregunta. drush makeEs conveniente para descargar módulos. No queremos contribuir a la hinchazón del módulo. Durante aquí se hace el caso de no extender makede esta manera. Quizás Características es mejor para administrar el estado habilitado del módulo del sitio, así como otros aspectos de configuración.

— Screenack
fuente
1

Considere modificar su flujo de trabajo.

Parece que quiere hacer un trabajo distribuido y "compartir" módulos habilitadores y otros valores de configuración ... de alguna manera.

Si lo piensa, incluso Drupal "core" y Drupal.org no hacen esto. El código se envía a los módulos principales y de la comunidad que se ejecutan en un proceso de construcción continua. Drupal.org y muchos proyectos usan Jenkins.

Para una instalación de Jenkins orientada al desarrollo de Drupal, también usa Phing, vea este repositorio de git: http://reload.github.io/jenkins-drupal-template/

Con Jenkins, puede insertar código en su repositorio maestro de Git y hacer que el sitio se cree para un sitio de demostración desde su Perfil de instalación y Drush Makefile (s). Esto no resuelve su problema exactamente, pero proporciona 1 ubicación en la que todos presionan los cambios para agregar / habilitar / eliminar módulos y esperamos que no "rompan la compilación".

Asumiendo que la construcción no está rota, es seguro llevar sus cambios a su sistema de desarrollo local.

Jenkins + un servidor de desarrollo o desarrollo es solo 1 pieza de desarrollo.

Su flujo de trabajo local puede usar perfiles de instalación + archivos MAKE. Considere compartir contenido utilizando módulos personalizados con Migrate si puede permitirse el tiempo de generación de contenido. Los ejemplos de compartir contenido con desarrolladores que usan Migrate, y el uso de Phing se pueden leer aquí:

http://marzeelabs.org/blog/2014/03/17/coding-as-a-team-content-fixtures/ http://marzeelabs.org/blog/2014/03/03/coding-as-a- equipo-automatización-usando-phing /

Por último, vea este PDF en una sesión de Drupal Camp Ohio 2014 sobre integración continua y trabajo con su equipo:

— Tenken
fuente
1

Para el mismo propósito estamos usando Master . Utiliza settings.php para proporcionar información sobre cuáles son los módulos maestros. Con un comando simple, drush master-executetodos los módulos (y sus dependencias) que faltan se habilitan y los módulos que ya no se usan se deshabilitan.

Actualmente, el módulo no lee información del archivo MAKE, pero tal vez esa podría ser una opción para una nueva versión.

— derhasi
fuente
0

Puede habilitar los módulos manualmente yendo a través de la opción Módulos o por terminal usando el comando drush

drush en -y modulename1 modulename2

y así.

— Nitesh Sethia
fuente
Estoy buscando una manera de automatizar esto basado en archivos MAKE, no solo cómo habilitar un módulo manualmente.
— dragonmantank
0

Los módulos se pueden habilitar de 2 maneras:

  1. ya sea desde la terminal usando el comando drush :
    A. drush dl modulename- para descargar el módulo primero
    B. drush en -y modulename- para habilitar el módulo

  2. Al usar la opción de menú Módulo y luego habilitar el módulo desde la cantidad de módulos que se muestran.

— neetu morwani
fuente
Estoy buscando una manera de automatizar esto basado en archivos MAKE, no solo cómo habilitar un módulo manualmente.
— dragonmantank
Hay algunas formas más. module_enable()por ejemplo. O importando una base de datos preparada.
— leymannx
0

Quiero un poco de esto que sea seguro. La función make se usa para descargar las diferentes partes del sitio: módulo, temas y proyecto a través de git. Cuando escribe su perfil de instalación, está escribiendo en el archivo de información los módulos dependientes. El problema es cuando necesita agregar un nuevo módulo para su perfil de instalación para el perfil existente. ¿Estoy en lo correcto?

Para eso necesitas usar hook_update_N cuando la N representa la actualización del número. El gancho se usa para módulos que necesitan realizar acciones como: actualizar esquemas, agregar variables y usarse para sitios y perturbaciones, como OpenScholar, para habilitar nuevos módulos descargados en el sitio en vivo.

Probablemente necesite agregar esto en el módulo más genérico y la función se verá así https://github.com/openscholar/openscholar/blob/SCHOLAR-3.x/openscholar/modules/os/os.install#L16

El gancho debe ubicarse en el archivo module.install. Si usa la interfaz de usuario, debe ir a www.site.com/update.php y si usa drush solo use el comando drush updb.

— Roy Segall
fuente
0

Según tengo entendido, el archivo Drush .make solo descarga proyectos de drupal.org, si desea habilitar algunos módulos, puede hacerlo con un perfil de instalación ** (.instalar) **. Un perfil de instalación le ofrece opciones, qué módulos desea habilitar en el momento de la instalación.

Recientemente también he contribuido con una distribución con la ayuda del archivo .make. Incluso compartí toda la experiencia de .make aquí . Sé que esto no está relacionado con lo que está preguntando exactamente, pero puede ayudarlo a comprender qué hace exactamente el archivo .make.

Entonces, de toda esta tarea, lo que entiendo, usando el archivo .make , no puede automatizar la habilitación del módulo. Para hacer esto, debe seguir algún otro enfoque.

Espero que esta URL del foro te pueda ayudar. Automatización de Drupal con scripts de Bash y Drush .

Necesita escribir un script bash donde exactamente usará los comandos Drush.

drush en -y modulename
— Pushpinder Rana
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.