web-dev-qa-db-fra.com

Quel est le bon flux de travail de mise à jour du noyau basé sur composer?

Je veux utiliser composer pour gérer Drupal 8 dépendances, mais je ne sais pas quel est le bon flux de travail de mise à jour de base. Pour le moment j'utilise drush pour mettre à jour le noyau vers la dernière version bêta, mais j'ai aussi quelques dépendances dans mon fichier composer.json, donc après la mise à jour j'utilise composer install pour installer toutes les dépendances des fournisseurs de contrib. Il semble que l'exécution de composer install remplace certains fichiers du répertoire core, bien que je viens de mettre à jour le core vers la dernière version.

J'ai également essayé de modifier manuellement le fichier composer.json et de remplacer la ligne "drupal/core" par la version bêta spécifique, par exemple "drupal/core": "~8.0-beta14",, mais il remplace toujours les fichiers du répertoire principal.

Quel est le bon workflow?

drush8updatingcomposer
16
rreiss

Je suppose que vous utilisez drupal-composer/drupal-project comme base de votre projet. Sinon, jetez un œil à ce projet et comparez-le avec le vôtre.

De plus, vous avez dit que vous vouliez utiliser composer pour gérer Drupal 8 dépendances, donc je suppose que vous avez sélectionné vos modules contrib via composer require drupal/devel plutôt que drush dl devel.

Si vous faites toutes ces choses, vous devez utiliser composer update pour mettre à jour Drupal core et tous vos modules contrib. Tant que vous conservez votre composer.lock fichier, composer install ne doit pas modifier la version de vos dépendances. Vous ne devez pas utiliser drush pm-update du tout. Peu importe que les fichiers du répertoire core soient mis à jour ou non, car ce répertoire est géré par Composer. Il vaut mieux ne pas engager de répertoires gérés par le compositeur dans votre référentiel, bien que vous puissiez le faire si vous le souhaitez.

Bien sûr, vous devez exécuter drush updatedb n'importe quand composer update remplace Drupal core ou tout module.

Pour éviter d'obtenir des versions de développement, définissez votre stabilité minimale sur "beta" dans votre fichier composer.json en utilisant Indicateurs de stabilité du compositeur .

Si vous utilisez drupal-composer/drupal-project pour gérer votre site, tous les fichiers de niveau racine tels que README.txt, .htaccess et index.html deviennent la propriété de votre projet. Cela signifie que vous devez les archiver dans votre référentiel git; Composer ne les mettra pas à jour, vous devez les mettre à jour vous-même lorsqu'ils changent. Ces fichiers ne devraient changer que rarement, mais drupal-composer/drupal-project a un script pour mettre à jour ces fichiers .

11
greg_1_anderson

Ce qui suit est OK pour les versions de correctifs 8.4.x> 8.4.y , mais pas OK pour les versions mineures 8.4. x> 8.5.x . Passez à MISE À JOUR 3 ci-dessous pour ce que je crois être "la réponse" pour les mises à jour de versions mineures.

1- Sauvegardez tous les fichiers fournis avec Drupal que vous avez modifiés, tels que .htaccess, robots.txt, etc. (ces 2 sont les plus souvent modifiés).

2- [On m'a dit que supprimer le fichier de verrouillage est incorrect, voir MISE À JOUR ci-dessous] Supprimez le fichier composer.lock (dans le dossier de niveau supérieur de votre site). Cela est recréé à l'étape 5.

3- Vérifiez votre composer.json (dans le dossier de niveau supérieur de votre site) et assurez-vous que le "drupal: core" est dans la section require et non dans une section de remplacement, par exemple

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

ne pas

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

Si "drupal/core" se trouve dans la section de remplacement, déplacez-le dans la section requise et supprimez la section de remplacement. S'il y a d'autres entrées dans la section de remplacement, supprimez simplement "drupal/core" et non la totalité de la section replace - mais je pense que "drupal/core" est normalement la seule chose là-bas.

Mettez la version à mettre à jour dans "drupal/core", exemples:

"drupal/core": "^ 8.5" - sera mis à jour vers la dernière version de 8.5. "drupal/core": "8.4.6" - sera mis à jour vers la version 8.4.6.

5- Exécutez ceci (dans le dossier de niveau supérieur de votre site):

composer update drupal/core --with-dependencies

6- S'il n'y a pas d'erreur, faites comme d'habitude, exécutez les mises à jour et videz le cache:

drush updatedb
drush cr

Ou si vous n'utilisez pas drush, accédez à /update.php pour exécuter les mises à jour, puis à admin/config/development/performance et appuyez sur le bouton "Effacer tous les caches".

7- Si vous aviez sauvegardé des fichiers dans la première étape (.htaccess, robots.txt), remettez-les en place. Mais vérifiez si Drupal a mis à jour ces fichiers et ajoutez ces modifications aux vôtres.

TERMINÉ

S'il y a eu des erreurs avec la mise à jour composer à l'étape 5, cela est généralement dû à des problèmes avec les versions des éléments dans le dossier du fournisseur.

Ceci est un excellent article pour traiter de ces problèmes: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update et lire les 2 autres de Jeff messages sur Drupal et Composer pour obtenir plus de connaissances à ce sujet.

Deux personnes m'ont dit sur Twitter que composer.lock ne devait pas être supprimé (étape 2 ci-dessus). La commande composer update drupal/core --with-dependencies Recrée quand même le fichier de verrouillage.

En testant cette méthode, je trouve que cela fonctionne bien pour 8.4.3> 8.4.6 (par exemple) mais j'obtiens des erreurs pour 8.4.6> 8.5.x. Je ferai rapport quand je le découvrirai.

Exemple d'erreurs:

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].

Cet article de Jeff Geerling traite de problèmes similaires, mais jusqu'à présent, pas de chance pour moi: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update =

Donc ... la seule chose qui semble fonctionner pour moi pour 8.4.x> 8.5.x est "l'option nucléaire" que tant d'autres semblent utiliser, qui est exécutée composer update.

Je suppose que c'est OK tant que vous êtes sûr des versions du module dans composer.json. Peut-être que l'on devrait les verrouiller dans la version actuelle. Par exemple:

"drupal/address": "1.3"

plutôt que:

"drupal/address": "^1.3"

Mais est-ce la bonne réponse?

OK la réponse qui semble être partout est de faire "l'option nucléaire":

A. Supprimez le dossier /vendor.

B. Exécutez composer update Et mettez simplement à jour vos modules avec le noyau. Ou, verrouillez les versions du module dans composer.json Si vous ne voulez pas les mettre à jour.

Une personne sur Drupal Slack a dit "toute la philosophie de Composer est que vous devriez toujours mettre à jour les packages, aussi souvent que possible) ". Packaged comprend des modules je pense. Donc, cela a du sens, je suppose.

Une fois que je suis passé de 8.4.6 à 8.5.0, cela a bien fonctionné pour passer de 8.5.0 à 8.5.1 composer update drupal/core --with-dependencies Tout comme pour 8.4.3 à 8.4.6.

Je commence à conclure que "la réponse" est que la suppression du dossier du fournisseur et du fichier composer.lock, puis l'utilisation de composer update Est très bien, et que l'on doit simplement s'assurer que les numéros de version des dépendances dans le compositeur. fichier json sont ce que vous voulez. Ce n'est pas si grave de gérer les versions de module que vous souhaitez conserver ou autoriser à mettre à jour dans composer.json.

Par exemple:

"drupal/admin_toolbar": "1.18", Signifie s'en tenir à 1,18

"drupal/admin_toolbar": "^1.18", Signifie aller de l'avant et mettre à jour mais dans les limites de 1.x (et non 2.x)

Ceci est soutenu par un commentaire (Général Redneck) sur ce post: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "L'une des choses que j'ai trouvées en travaillant à la prise en charge est que le verrouillage des versions des modules et du noyau est une bonne idée afin que vous puissiez thermonuke la chose quand vous le souhaitez car il y a des moments où certains des différents plugins ne veulent même pas se comporter correctement. "

Soit dit en passant, le fichier composer.lock n'est d'aucune aide avec composer update Car il est emporté (contrairement à composer install Où il verrouille le fichier est lu):

L'exécution de composer install:

  • Vérifiez si un composer.lock Existe
  • Sinon, effectuez un composer update Pour en créer un
  • Si composer.lock Existe, installez les versions spécifiées à partir du fichier de verrouillage

L'exécution de composer update:

  • Cochez composer.json
  • Déterminez les dernières versions à installer en fonction des spécifications de votre version
  • Installer les dernières versions
  • Mettez à jour composer.lock Pour refléter les dernières versions installées

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

Je vois que cela est mentionné ci-dessus: https://github.com/drupal-composer/drupal-project . Je l'ai utilisé et c'est très bien mais ce n'est pas une exigence pour utiliser Composer avec Drupal. C'est déroutant car il sorte de "sonne" comme il vient du nom. Quand j'ai commencé avec Drupal 8 Je pensais que c'était nécessaire, alors j'ai construit mon premier site D8 avec ça, pensant que c'était la meilleure pratique.

Cette "version" de Drupal a docroot dans un dossier/web, pas dans le dossier supérieur du projet. Il y a aussi un tas de choses ajoutées à .gitignore par rapport à Drupal normal:

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

Donc, cette version de Drupal est vraiment plus destinée aux sites qui utilisent l'intégration continue pour faire une nouvelle version de Drupal sur chaque déploiement, en utilisant composer install. Si vous déployez avec une méthode plus normale, vous devez évidemment valider toutes les choses ci-dessus dans votre dépôt git ou il ne sera pas déployé sur votre serveur [1], et toutes ces choses sont nécessaires pour Drupal à exécuter.

[1] si git est impliqué dans votre déploiement - si vous déployez avec SFTP, ignorez cela.

2
Richard Hood

Oui, vous pouvez gérer Drupal core avec le compositeur. Il y a quelques choses à savoir cependant.

Vous obtiendrez probablement des délais d'attente en raison d'un certain nombre d'éléments composer doit être exécuté, surtout si vous exécutez dans une machine virtuelle locale. Si vous exécutez composer install vous obtiendrez probablement l'erreur composer:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Assurez-vous d'utiliser

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

Ajoutez également une extension au délai d'expiration dans la configuration

    "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
       },

De plus, si cela ne fonctionne pas, vous pouvez exécuter composer install depuis l'extérieur SSH dans votre VM.

Cela contournera tous les délais d'attente de partage NFS et décompressera Drupal au bon endroit).

1
BigEd

En utilisant le paquet drupal/core sur packagist.org nous pouvons réellement gérer le noyau, les modules contrib (, thèmes et profils) et les autres fournisseurs via composer.

J'ai installé les fichiers suivants dans mon répertoire racine et exécuté 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

Prendre plaisir :)

1
Eyal

"drupal/core": "~ 8.0-beta14" signifie toute version supérieure à 8.0-beta14 et inférieure à 9! Vous souhaiterez supprimer le tilde pour le verrouiller sur une version spécifique. Assurez-vous ensuite de mettre à jour votre fichier de verrouillage en exécutant composer up, et sur le système cible, utilisez composer install.

Un moyen simple de commencer est de construire la base de code en utilisant https://github.com/drupal-composer/drupal-project .

Lorsque nous devons mettre à jour quelque chose comme la mise à niveau du noyau, vous exécutez "composer up" localement. Cela mettra à jour le fichier composer.lock.

Lorsque d'autres développeurs tirent vers le bas, ou dans un script de déploiement, vous exécutez "Composer Install", qui utilise le fichier de verrouillage.

La ligne dans notre composer.json pour Drupal core est:

"drupal/core": "~8.0",

Le tilde () signifie toute version dans le nombre 8 (mais pas 9) .

Si vous souhaitez le verrouiller sur une version spécifique, vous ne devez pas utiliser le tilde.

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

puis exécutez "composer up" localement, validez les fichiers composer.json et composer.lock, puis exécutez "composer install" sur d'autres installations après avoir déroulé la base de code.

0
oknate