Каков правильный рабочий процесс обновления ядра на основе композитора?

16

Я хочу использовать composer для управления зависимостями Drupal 8, но я не уверен, каков правильный рабочий процесс обновления ядра. В настоящее время я использую drush для обновления ядра до последней бета-версии, но у меня также есть некоторые зависимости в моем файле composer.json, поэтому после обновления я использую установку composer для установки всех зависимостей поставщика contrib. Похоже, что запуск composer installпереопределяет некоторые файлы в директории ядра, хотя я только что обновил ядро ​​до последней версии.

Я также попытался вручную отредактировать файл composer.json и заменить строку «drupal / core» на конкретную бета-версию, например "drupal/core": "~8.0-beta14", , но она все равно переопределяет файлы в директории core.

Каков правильный рабочий процесс?

rreiss
источник

Ответы:

11

Я предполагаю, что вы используете drupal-composer / drupal-project в качестве основы для вашего проекта. Если нет, взгляните на этот проект и сравните его с вашим.

Кроме того, вы сказали, что хотите использовать composer для управления зависимостями Drupal 8, поэтому я предполагаю, что вы выбрали свои модули contrib через, composer require drupal/develа не drush dl devel.

Если вы делаете все эти вещи, то вы должны использовать composer updateдля обновления ядра Drupal и всех ваших модулей contrib. Пока вы сохраняете свой composer.lockфайл, composer installне следует менять версию какой-либо из ваших зависимостей. Вы не должны использовать drush pm-updateвообще. Для вас не должно иметь значения, находятся ли файлы вcore , обновляются каталоге или нет, так как этим каталогом управляет Composer. Вам лучше не помещать управляемые композитором каталоги в свой репозиторий, хотя вы можете, если хотите.

Конечно, вы должны запускаться drush updatedbвсякий раз, когда composer updateзаменяет ядро ​​Drupal или любой модуль.

Чтобы избежать получения версий для разработки, установите минимальную стабильность на уровне «бета» в файле composer.json, используя флаги стабильности Composer .

Если вы используете drupal-composer / drupal-project для управления вашим сайтом, то все файлы корневого уровня, такие как README.txt, .htaccess и index.html, становятся собственностью вашего проекта. Это означает, что вы должны зарегистрировать их в своем репозитории git; Composer не будет обновлять их, вы должны обновить их самостоятельно, когда они изменятся. Эти файлы должны изменяться очень редко, но у drupal-composer / drupal-project есть скрипт для обновления этих файлов .

greg_1_anderson
источник
Предположим, что я использую обновление композитора вместо drush pm-update, как мне обновить такие файлы, как README.txt, .htaccess и т. Д.? И как получается, что drush update дает другое ядро, чем композиторское обновление? И должен ли я заменять версию drupal в моем composer.json на 8.0-betaX перед каждым обновлением? Я не хочу использовать Dev. версия ..
Rreiss
Обновил ответ.
greg_1_anderson
+1 greg_1_anderson - это выглядит великолепно, это лучший способ сделать обновления безопасности для Drupal 8? с D7 это: drupal.stackexchange.com/a/71578
therobyouknow
Похоже, это работает, если изначально установить Drupal 8.1 с помощью следующих шагов: drupal.org/node/2471553 (я обнаружил, что это работает без ошибок)
therobyouknow
«Конечно, вы должны запускаться drush updatedbвсякий раз, когда обновление композитора заменяет ядро ​​Drupal или любой другой модуль». - спасибо, и если вы изначально установили drupal с этими шагами, drupal.org/node/2471553, то вам нужен полный путь к конкретной загрузке с вашей установкой Drupal 8 (так как они использовали для запуска установки в качестве последнего шага). Сначала вам нужно войти в web, а затем в / web команда для обновления БД с полным путем будет выглядеть так: ../vendor/drush/drush/drush updatedb(я нашел, что это работает).
therobyouknow
2

Ниже КИ для патча - релизов 8.4.x> 8.4.y , но не нормальны для незначительных выпусков 8.4.x> 8.5.x . Перейдите к ОБНОВЛЕНИЮ 3 ниже, чтобы найти ответ на небольшие обновления.

1- Сделайте резервную копию любых файлов, которые поставляются с Drupal, которые вы изменили, таких как .htaccess, robots.txt и т. Д. (Эти 2 наиболее часто изменяются).

2- [Мне сказали, что удалить файл блокировки неправильно, см. ОБНОВЛЕНИЕ ниже] Удалите файл composer.lock (в папке верхнего уровня вашего сайта). Это воссоздается в шаге 5.

3- Проверьте ваш composer.json (в папке верхнего уровня вашего сайта) и убедитесь, что «drupal: core» находится в разделе require, а не в разделе replace, например.

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

не

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

Если «drupal / core» находится в разделе замены, переместите его в необходимый раздел и удалите раздел замены. Если в разделе замены есть другие записи, просто удалите "drupal / core", а не весь раздел замены - но я думаю, что "drupal / core", как правило, единственное, что есть.

Поместите, какую версию вы хотите обновить в "drupal / core", примеры:

"drupal / core": "^ 8.5" - обновится до последней версии 8.5. "drupal / core": "8.4.6" - обновится до версии 8.4.6.

5- Запустите это (в папке верхнего уровня вашего сайта):

composer update drupal/core --with-dependencies

6- Если ошибок нет, то сделайте как обычно, запустите обновления и очистите кеш:

drush updatedb
drush cr

Или, если не используется drush, перейдите в /update.php для запуска обновлений, затем в admin / config / development / performance и нажмите кнопку «Очистить все кеши».

7- Если вы сделали резервные копии файлов на первом этапе (.htaccess, robots.txt), верните их обратно. Но проверьте, сделал ли Drupal обновления для этих файлов, и добавьте эти изменения к вашим.

СДЕЛАНО

Если при обновлении композитора на шаге 5 возникли ошибки, это обычно происходит из-за проблем с версиями материала в папке vendor.

Это отличный пост по решению таких проблем: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update и прочитайте другие 2 поста Джеффа о Drupal и Composer, чтобы получить больше знаний об этом.

Мне сказали 2 человека в Твиттере, что composer.lock не должен быть удален (Шаг 2 выше). Команда composer update drupal/core --with-dependenciesвоссоздает файл блокировки в любом случае.

При тестировании этого метода я считаю, что он работает нормально для 8.4.3> 8.4.6 (например), но я получаю ошибки для 8.4.6> 8.5.x. Отзовусь, когда я это выясню.

Пример ошибок:

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

Этот пост Джеффа Герлинга посвящен аналогичным проблемам, но пока мне не повезло: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update

Так что ... единственное, что мне подходит для 8.4.x> 8.5.x - это "ядерный вариант", который, похоже, используют многие другие, который запускается composer update.

Я думаю, это нормально, если вы уверены в версиях модуля в composer.json. Возможно, следует заблокировать их до текущей версии. Например:

"drupal/address": "1.3"

скорее, чем:

"drupal/address": "^1.3"

Но правильный ли это ответ?

ОК, ответ, который кажется повсюду, состоит в том, чтобы сделать «ядерный вариант»:

А. Удалить /vendorпапку.

Б. Запустите composer updateи просто обновите ваши модули вместе с ядром. Или заблокируйте версии модулей, composer.jsonесли вы не хотите их обновлять.

Один человек из Drupal Slack сказал: «Вся философия Composer заключается в том, что вы всегда должны обновлять пакеты как можно чаще» . Пакет включает в себя модули, я думаю. Так что в этом есть какой-то смысл.

Как только я получил от 8.4.6 до 8.5.0, это работало нормально, чтобы получить от 8.5.0 до 8.5.1, composer update drupal/core --with-dependenciesкак это было для 8.4.3 до 8.4.6.

Я начинаю заключать, что «ответ» заключается в том, что удаление папки vendor и файла composer.lock с последующим использованием composer update- это нормально, и что нужно просто убедиться, что номера версий для зависимостей в файле composer.json - это то, что вам нужно , Не так уж сложно управлять тем, какие версии модулей вы хотите сохранить или разрешить обновлять composer.json.

Например:

"drupal/admin_toolbar": "1.18", значит придерживаться 1,18

"drupal/admin_toolbar": "^1.18", означает идти вперед и обновлять, но в пределах 1.x (не 2.x)

Это подтверждается комментарием (General Redneck) к этому сообщению: https://www.jeffgeerling.com/blog/2018/updating-drupalcore-composer-drupal-core-doesnt-update "Одна из вещей, которые я Когда я работаю в поддержке, я обнаружил, что блокировка версий модулей и ядра - это хорошая идея, так что вы МОЖЕТЕ сделать это, когда захотите, потому что бывают случаи, когда некоторые из различных плагинов даже не хотят работать правильно ».

Между прочим, файл composer.lock не помогает, composer updateпотому что он сдулся (в отличие от того, composer installгде он читает файл блокировки):

Бег composer installбудет:

  • Проверьте, composer.lockсуществует ли
  • Если нет, выполните composer updateдля его создания
  • Если composer.lockсуществует, установите указанные версии из файла блокировки

Бег composer updateбудет:

  • Проверьте composer.json
  • Определите последние версии для установки на основе ваших спецификаций версий
  • Установите последние версии
  • Обновление composer.lockдля отображения последних установленных версий

Ссылка: https://www.engineyard.com/blog/composer-its-all-about-the-lock-file

Я вижу, что это упомянуто выше: https://github.com/drupal-composer/drupal-project . Я использовал это, и это нормально, но это не является обязательным требованием для использования Composer с Drupal. Это сбивает с толку, как будто "звучит", как будто это из названия. Когда я впервые начал работать с Drupal 8, я думал, что это необходимо, поэтому построил свой первый сайт на D8, полагая, что это лучшая практика.

Эта «версия» Drupal имеет docroot в папке / web, а не в верхней папке проекта. Также к .gitignore добавлено несколько вещей по сравнению с обычным Drupal:

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

Итак, эта версия Drupal действительно больше предназначена для сайтов, которые используют непрерывную интеграцию для создания новой сборки Drupal при каждом развертывании, используя установку composer. Если вы используете более обычный метод, вам, очевидно, придется зафиксировать все вышеперечисленное в своем git-репо, иначе он не будет развернут на вашем сервере [1], и все это необходимо для работы Drupal.

[1] если git участвует в вашем развертывании - если вы развертываете с SFTP, игнорируйте это.

Ричард Худ
источник
composer update drupal/core symfony/config webflo/drupal-core-strict --with-dependenciesникогда не подводил меня еще. Работает над несколькими второстепенными версиями, например, 8.3 -> 8.6
Клайв
1

Используя пакет drupal / core на packagist.org, мы можем управлять ядром, модулями contrib (темами и профилями) и другими поставщиками через composer.

Я установил следующие файлы в моем корневом каталоге и выполнил 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

Наслаждаться :)

Эяль
источник
Думаю, мне понадобится вся та магия скручивания, которую вы сделали. Я ожидал, что все эти необходимые файлы будут размещены композитором.
dxvargas
@hiphip Файлы за пределами основного каталога меняются не часто, поэтому приведенное выше может быть сценарием, который вы выполняете вручную, когда drupal обновляет одну минорную версию на другую (т. е. с 8.1 до 8.2)
Eyal
1

Да, вы можете управлять ядром Drupal с помощью composer. Есть несколько вещей, о которых нужно знать, хотя.

Вы, вероятно, получите тайм-ауты из-за ряда элементов, которые должен пройти композитор, особенно если вы работаете в локальной виртуальной машине. Если вы запустите, composer installвы, скорее всего, получите ошибку композитора:

 [RuntimeException]                                    
  Could not delete core/.nfs0000000000000000000001:

Убедитесь, что вы используете требовать

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

Также добавьте расширение к таймауту в конфиге

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

Также, если это не сработает, вы можете запустить установку composer из-за пределов SSH в вашей виртуальной машине .

Это позволит обойти таймауты общего ресурса NFS и распаковать Drupal в нужном месте.

BigED
источник
0

«drupal / core»: «~ 8.0-бета14» означает любой выпуск больше 8.0-бета14 и меньше 9! Вы захотите удалить тильду, чтобы заблокировать ее для определенного выпуска. Затем убедитесь, что обновили файл блокировки, запустив composer up, и в целевой системе используйте composer install.

Самый простой способ начать работу - создать базу кода, используя https://github.com/drupal-composer/drupal-project .

Когда нам нужно обновить что-то, например, обновить ядро, вы запускаете «composer up» локально. Это обновит файл composer.lock.

Когда другие разработчики завершают работу или в сценарии развертывания вы запускаете «composer install», которая использует файл блокировки.

Строка в нашем composer.json для ядра Drupal:

"drupal/core": "~8.0",

Тильда () означает любой выпуск в пределах числа 8 (но не 9) .

Если вы хотите привязать его к определенной версии, вы не должны использовать тильду.

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

затем запустите «composer up» локально, зафиксируйте файл composer.json и composer.lock, а затем запустите «composer install» в других установках после удаления базы кода.

oknate
источник