¿Cuál es el flujo de trabajo de actualización de núcleo basado en compositor correcto?

16

Quiero usar Composer para administrar las dependencias de Drupal 8, pero no estoy seguro de cuál es el flujo de trabajo de actualización central correcto. En este momento estoy usando drush para actualizar el núcleo a la última versión beta, pero también tengo algunas dependencias en mi archivo composer.json, así que después de la actualización estoy usando la instalación de composer para instalar todas las dependencias de los proveedores contrib. Parece que la ejecución composer installanula algunos archivos en el directorio central, aunque acabo de actualizar el núcleo a la última versión.

También he intentado editar manualmente el archivo composer.json y reemplazar la línea "drupal / core" con la versión beta específica, por ejemplo "drupal/core": "~8.0-beta14",, pero aún anula los archivos en el directorio central.

¿Cuál es el flujo de trabajo correcto?

rreiss
fuente

Respuestas:

11

Supongo que está utilizando drupal-composer / drupal-project como base para su proyecto. Si no, eche un vistazo a ese proyecto y compárelo con el suyo.

Además, dijo que desea utilizar el compositor para administrar las dependencias de Drupal 8, por lo que supongo que ha seleccionado sus módulos contrib a través de en composer require drupal/devellugar de hacerlo drush dl devel.

Si está haciendo todas estas cosas, debe usar composer updatepara actualizar Drupal core y todos sus módulos contrib. Siempre y cuando conserve su composer.lockarchivo, composer installno debe cambiar la versión de ninguna de sus dependencias. No debes usar drush pm-updateen absoluto. No debería importarle si los archivos en el coredirectorio se actualizan o no, ya que Composer administra este directorio. Es mejor no comprometer directorios administrados por el compositor en su repositorio, aunque puede hacerlo si lo desea.

Por supuesto, debe ejecutar drush updatedbsiempre que composer updatereemplace el núcleo de Drupal o cualquier módulo.

Para evitar obtener versiones de desarrollo, establezca su estabilidad mínima en 'beta' en su archivo composer.json utilizando las banderas de estabilidad Composer .

Si está utilizando drupal-composer / drupal-project para administrar su sitio, todos los archivos de nivel raíz como README.txt, .htaccess e index.html serán propiedad de su proyecto. Eso significa que debe registrarlos en su repositorio git; Composer no los actualizará, debe actualizarlos usted mismo cuando cambien. Estos archivos deberían cambiar solo en raras ocasiones, pero drupal-composer / drupal-project tiene un script para actualizar estos archivos .

greg_1_anderson
fuente
Supongamos que estoy usando la actualización del compositor en lugar de drush pm-update, ¿cómo actualizo archivos como README.txt, .htaccess, etc.? ¿Y por qué la actualización drush proporciona un núcleo diferente al de la actualización del compositor? ¿Y debo reemplazar la versión de drupal en mi composer.json a 8.0-betaX antes de cada actualización? No quiero usar dev. versión ..
rreiss
Se actualizó la respuesta.
greg_1_anderson
+1 greg_1_anderson: esto se ve genial, ¿es esta la forma definitiva de hacer actualizaciones de seguridad para Drupal 8? con D7, es: drupal.stackexchange.com/a/71578
therobyouknow
Parece que funciona si uno hubiera instalado inicialmente Drupal 8.1 con estos pasos: drupal.org/node/2471553 (encontré que esto funciona sin error)
therobyouknow
"Por supuesto, debe ejecutar drush updatedbcada vez que la actualización del compositor reemplace el núcleo de Drupal o cualquier módulo". - gracias y si inicialmente instaló drupal con estos pasos, drupal.org/node/2471553 , entonces necesita la ruta completa al drush particular con su instalación de Drupal 8 (ya que solían ejecutar la instalación como el paso final). Primero necesita cd en la web y, una vez en / web, el comando para actualizar el db con la ruta completa sería: ../vendor/drush/drush/drush updatedb(Encontré que esto funciona).
therobyouknow
2

A continuación está bien para parche libera 8.4.x> 8.4.y , pero no está mal para versiones menores 8.4.x> 8.5.x . Vaya a la ACTUALIZACIÓN 3 a continuación para ver lo que creo que es "la respuesta" para actualizaciones de lanzamiento menores.

1- Haga una copia de seguridad de cualquier archivo que venga con Drupal que haya modificado, como .htaccess, robots.txt, etc. (esos 2 son los que se cambian más comúnmente).

2- [Me dijeron que eliminar el archivo de bloqueo es incorrecto, vea ACTUALIZAR a continuación] Elimine el archivo composer.lock (en la carpeta de nivel superior de su sitio). Esto se recrea en el paso 5.

3- Verifique su composer.json (en la carpeta de nivel superior de su sitio) y asegúrese de que "drupal: core" esté en la sección de requisitos y no en una sección de reemplazo, por ejemplo

"require": {
"drupal/core": "^8.4"
},

no

"replace": {
"drupal/core": "^8.4"
},

Si "drupal / core" está en la sección de reemplazo, muévalo a la sección requerida y elimine la sección de reemplazo. Si hay otras entradas en la sección de reemplazo, simplemente elimine "drupal / core", no toda la sección de reemplazo, pero creo que "drupal / core" es normalmente lo único que hay.

Ponga a qué versión desea actualizar en "drupal / core", ejemplos:

"drupal / core": "^ 8.5" - se actualizará a la última versión de 8.5. "drupal / core": "8.4.6" - se actualizará a la versión 8.4.6.

5- Ejecute esto (en la carpeta de nivel superior de su sitio):

composer update drupal/core --with-dependencies

6- Si no hay errores, haz lo habitual, ejecuta las actualizaciones y borra la memoria caché:

drush updatedb
drush cr

O si no usa drush, vaya a /update.php para ejecutar actualizaciones, luego a admin / config / development / performance y presione el botón "Borrar todas las cachés".

7- Si ha realizado una copia de seguridad de los archivos en el primer paso (.htaccess, robots.txt), vuelva a colocarlos. Pero verifique si Drupal realizó actualizaciones a esos archivos y agregue esos cambios a los suyos.

HECHO

Si hubo errores con la actualización del compositor en el paso 5, generalmente se debe a problemas con las versiones de las cosas en la carpeta del proveedor.

Esta es una gran publicación para tratar estos problemas: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update y lea las otras 2 publicaciones de Jeff en Drupal y Composer para obtener más conocimiento sobre eso.

2 personas en Twitter me dijeron que composer.lock no debería eliminarse (Paso 2 anterior). El composer update drupal/core --with-dependenciescomando recrea el archivo de bloqueo de todos modos.

Al probar este método, encuentro que funciona bien para 8.4.3> 8.4.6 (por ejemplo) pero obtengo errores para 8.4.6> 8.5.x. Informaré cuando lo resuelva.

Ejemplo de errores:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - symfony/yaml 3.4.x-dev conflicts with symfony/console[v3.2.8].
    - drupal/core 8.5.0 requires symfony/yaml ~3.4.5 -> satisfiable by symfony/yaml[3.4.x-dev].
    - Installation request for drupal/core 8.5.0 -> satisfiable by drupal/core[8.5.0].
    - Installation request for symfony/console (locked at v3.2.8, required as ~3.2.8) -> satisfiable by symfony/console[v3.2.8].

Esta publicación de Jeff Geerling aborda problemas similares, pero hasta ahora no tuve suerte: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update

Entonces ... lo único que parece funcionar para mí para 8.4.x> 8.5.x es la "opción nuclear" que muchos otros parecen usar, que se ejecuta composer update.

Supongo que está bien siempre que esté seguro de las versiones del módulo en composer.json. Tal vez uno debería bloquearlos a la versión actual. Por ejemplo:

"drupal/address": "1.3"

más bien que:

"drupal/address": "^1.3"

¿Pero es la respuesta correcta?

OK, la respuesta que parece estar en todas partes es hacer la "opción nuclear":

A. Eliminar la /vendorcarpeta.

B. Ejecute composer updatey simplemente actualice sus módulos junto con core. O bloquee las versiones del módulo composer.jsonsi no desea actualizarlas.

Una persona en Drupal Slack dijo que "toda la filosofía de Composer es que siempre debe actualizar los paquetes, con la mayor frecuencia posible" . Empaquetado incluye módulos, creo. Entonces tiene sentido, supongo.

Una vez que pasé de 8.4.6 a 8.5.0, funcionó bien para pasar de 8.5.0 a 8.5.1 composer update drupal/core --with-dependenciestal como lo hizo para 8.4.3 a 8.4.6.

Estoy empezando a concluir que "la respuesta" es que eliminar la carpeta del proveedor y el archivo composer.lock, luego usarlo composer updateestá bien, y que uno simplemente debe asegurarse de que los números de versión para las dependencias en el archivo composer.json sean lo que desea . No es tan importante administrar las versiones de módulos que desea mantener o permitir actualizar composer.json.

Por ejemplo:

"drupal/admin_toolbar": "1.18", significa quedarse con 1.18

"drupal/admin_toolbar": "^1.18", significa seguir adelante y actualizar, pero dentro de 1.x (no 2.x)

Esto está respaldado por un comentario (General Redneck) en esta publicación: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "Una de las cosas que he descubrí que trabajar como soporte es que bloquear las versiones de los módulos y el núcleo es una buena idea para que PUEDAS avisar cuando lo desees porque a veces algunos de los diversos complementos incluso no quieren comportarse correctamente ".

Por cierto, el archivo composer.lock no ayuda composer updateporque se vuela (en lugar de composer installdonde se lee el archivo de bloqueo):

Correr composer install:

  • Comprobar si composer.lockexiste
  • Si no, realice una composer updatepara crear uno
  • Si composer.lockexiste, instale las versiones especificadas del archivo de bloqueo

Correr composer update:

  • Cheque composer.json
  • Determine las últimas versiones para instalar según las especificaciones de su versión
  • Instala las últimas versiones
  • Actualización composer.lockpara reflejar las últimas versiones instaladas

Ref: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file

Veo que esto se menciona anteriormente: https://github.com/drupal-composer/drupal-project . Lo he usado y está bien, pero no es un requisito para usar Composer con Drupal. Es confuso ya que "suena" como si fuera del nombre. Cuando comencé con Drupal 8, pensé que era necesario, así que construí mi primer sitio D8 con eso, pensando que era la mejor práctica.

Esa "versión" de Drupal tiene docroot en una carpeta / web, no en la carpeta superior del proyecto. También hay un montón de cosas agregadas a .gitignore en comparación con Drupal normal:

/drush/contrib/
/vendor/
/web/core/
/web/modules/contrib/
/web/themes/contrib/
/web/profiles/contrib/
/web/libraries/

Por lo tanto, esta versión de Drupal está realmente más destinada a sitios que utilizan la integración continua para hacer una nueva compilación de Drupal en cada implementación, utilizando la instalación del compositor. Si implementa con un método más normal, obviamente tiene que enviar todo lo anterior a su repositorio git o no se implementará en su servidor [1], y todo eso es necesario para que Drupal se ejecute.

[1] si git está involucrado en su implementación, si implementa con SFTP, ignórelo.

Richard Hood
fuente
composer update drupal/core symfony/config webflo/drupal-core-strict --with-dependenciesNunca me ha fallado todavía. Funciona en varias versiones menores, por ejemplo, 8.3 -> 8.6
Clive
1

Usando el paquete drupal / core en packagist.org podemos administrar el núcleo, los módulos contrib (temas y perfiles) y los otros proveedores a través del compositor.

He configurado los siguientes archivos en mi directorio raíz y ejecuté composer install

composer.json

{
  "require": {
    "composer/installers": "^1.0.20",
    "drupal/core": "8.0.*"
  },
  "extra": {
    "installer-paths": {
      "core": ["type:drupal-core"],
      "modules/contrib": ["type:drupal-module"],
      "profiles/contrib": ["type:drupal-profile"],
      "themes/contrib": ["type:drupal-theme"]
    }
  },
  "scripts": {
    "post-install-cmd": [
      "./post_install.sh"
    ]
  }
}

post_install.sh

#!/usr/bin/env bash
export RAW_DRUPAL="https://raw.githubusercontent.com/drupal/drupal/8.0.x"
curl $RAW_DRUPAL/example.gitignore > example.gitignore
curl $RAW_DRUPAL/.gitattributes > .gitattributes
curl $RAW_DRUPAL/.htaccess > .htaccess
curl $RAW_DRUPAL/.csslintrc > .csslintrc
curl $RAW_DRUPAL/.editorconfig > .editorconfig
curl $RAW_DRUPAL/.eslintrc > .eslintrc
curl $RAW_DRUPAL/.eslintignore > .eslintignore
curl $RAW_DRUPAL/index.php > index.php
curl $RAW_DRUPAL/update.php > update.php
curl $RAW_DRUPAL/web.config > web.config
curl $RAW_DRUPAL/autoload.php > autoload.php
curl $RAW_DRUPAL/robots.txt > robots.txt
mkdir -p sites/default
curl $RAW_DRUPAL/sites/example.sites.php > sites/example.sites.php
curl $RAW_DRUPAL/sites/development.services.yml > sites/development.services.yml
curl $RAW_DRUPAL/sites/example.settings.local.php > sites/example.settings.local.php
curl $RAW_DRUPAL/sites/default/default.services.yml > sites/default/default.services.yml
curl $RAW_DRUPAL/sites/default/default.settings.php > sites/default/default.settings.php

Disfruta :)

Eyal
fuente
Supongo que necesitaré toda esa magia rizada que hayas hecho. Esperaba que el compositor pusiera en práctica todos estos archivos necesarios.
dxvargas
@hiphip Los archivos fuera del directorio principal no cambian con frecuencia, por lo que lo anterior podría ser un script que ejecute manualmente cuando drupal actualice de una versión menor a la siguiente (es decir, 8.1 a 8.2)
Eyal
1

Sí, puedes administrar el núcleo de Drupal con el compositor. Sin embargo, hay un par de cosas a tener en cuenta.

Probablemente obtendrá tiempos de espera debido a la cantidad de elementos que el compositor debe ejecutar, especialmente si se ejecuta en una VM local. Si ejecuta, composer installes probable que obtenga el error del compositor:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Asegúrate de usar require

{
  "require": {
   "drupal/core": "8.3.*"

Agregue también una extensión al tiempo de espera en la configuración

    "installer-paths": {
        "core": ["type:drupal-core"],
        "modules/contrib/{$name}": ["type:drupal-module"],
        "profiles/contrib/{$name}": ["type:drupal-profile"],
        "themes/contrib/{$name}": ["type:drupal-theme"],
        "drush/contrib/{$name}": ["type:drupal-drush"],
        "modules/custom/{$name}": ["type:drupal-custom-module"],
        "themes/custom/{$name}": ["type:drupal-custom-theme"]
    }
},

"config":{
            "process-timeout": 1600
       },

Además, si eso no funciona, puede ejecutar la instalación del compositor desde fuera de SSH en su VM .

Esto evitará cualquier tiempo de espera de compartir NFS y desempaquetará Drupal en el lugar correcto.

BigEd
fuente
0

"drupal / core": "~ 8.0-beta14" significa cualquier versión mayor que 8.0-beta14 y menor que 9. Deberá eliminar la tilde para bloquearla en una versión específica. Luego, asegúrese de actualizar su archivo de bloqueo ejecutando Composer Up, y en el sistema de destino use la instalación de Composer.

Una manera fácil de comenzar es construir la base de código usando https://github.com/drupal-composer/drupal-project .

Cuando necesitamos actualizar algo como actualizar core, ejecutas "composer up" localmente. Esto actualizará el archivo composer.lock.

Cuando otros desarrolladores despliegan, o en una secuencia de comandos de implementación, ejecuta "instalación del compositor", que utiliza el archivo de bloqueo.

La línea en nuestro composer.json para Drupal core es:

"drupal/core": "~8.0",

La tilde () significa cualquier liberación dentro del número 8 (pero no 9) .

Si desea bloquearlo a una versión específica, no debe usar la tilde.

"drupal/core": "8.0-beta14",

luego ejecute "composer up" localmente, confirme el archivo composer.json y composer.lock, y luego ejecute "composer install" en otras instalaciones después de desplegar la base de código.

oknate
fuente