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

  1. Я скачал и запустил среду разработки (crafter-cms-authoring.zip)
  2. Создан сайт, поддерживаемый удаленным репозиторием git, как описано в: Создать сайт на основе схемы, а затем отправить на удаленный голый git-репозиторий
  3. Создал тип контента, новую страницу.
  4. Опубликовано все

Теперь я ожидаю, что смогу увидеть свои изменения в удаленном репо. Но все, что я вижу, это начальные коммиты из шага 2. выше. Нет нового типа контента, нет новой страницы, нет живой ветки. (Однако элементы контента видны в локальном репо)

Чего не хватает?

Редактировать: Поскольку Creafter можно настроить разными способами, чтобы прояснить мой сценарий развертывания, я добавляю схему развертывания + краткое описание.

headless deploy Есть 3 хоста — по одному для каждой среды + общий репозиторий git.

Авторство
Здесь находится студия, где авторы контента вносят изменения. Каждое изменение сохраняется в sandbox локальном репозитории git. Когда контент публикуется, изменения загружаются в published локальный репозиторий git. Эти два локальных репозитория недоступны с других хостов.

Доставка
Это то, что предоставляет опубликованный контент конечному пользователю/приложению. Deployer отвечает за получение новых публикаций в экземпляре доставки. Он делает это, опрашивая (периодически извлекая) конкретный репозиторий git. Когда он извлекает новые изменения, он обновляет индексы локального репозитория git site и Solr.

Gitlab
Здесь размещен репозиторий git site. Он доступен как с узлов разработки, так и с узлов доставки. После создания новый site помещается в этот репозиторий. Репозиторий также опрашивается на наличие новых изменений Deployers экземплярами доставки.

Чтобы эта настройка работала, опубликованные изменения должны каким-то образом попасть в репозиторий Gitlab site, но это не так (красный путь связи от Authoring Deployer к Gitlab site).

Решение на основе ответа @summerz

Я реализовал GitPushProcessor и настроил новую цель развертывания при разработке Deployer, добавив mysite-live.yaml к /opt/crafter-cms-authoring/data/deployer/target/:

target:
    env: live
    siteName: codelists
    engineUrl: http://localhost:9080
    localRepoPath: /opt/crafter-cms-authoring/data/repos/sites/mysite/published 
    deployment:
        pipeline:
        - processorName: gitPushProcessor
            remoteRepo:
                url: ssh://path/to/gitlab/site/mysite

crafter-cms
person Maros Ivanco    schedule 26.03.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я думаю, вы могли перепутать push с publish.

При публикации

Authoring (Studio) публикуется в Delivery (Engine) после рабочего процесса утверждения, который запускает контент. Авторинг — это когда контент (и код, если хотите) управляется и безопасно просматривается, а затем публикуется на узлах оперативной доставки для доставки конечному пользователю.

О DevOps

Локальный git-репозиторий сайта можно передавать/извлекать в/из удаленных репозиториев. Это означает:

  • Код может передаваться с рабочей станции разработчика в Studio (через github, gitlab, bitbucket и т. д.) ‹== код движется вперед (и может передаваться через такие среды, как контроль качества, нагрузочное тестирование и т. д.)
  • Контент может передаваться обратно из Studio на локальную рабочую станцию ​​разработчика аналогичным образом ‹== это контент, перемещающийся в обратном направлении (вы можете иметь производственный контент на своем ноутбуке, если хотите)

Когда код передается от разработчика в Studio, именно тогда Studio извлекает данные из удаленного репозитория git.

Когда содержимое передается от Studio к разработчику, именно тогда Studio отправляет его в удаленный репозиторий git.

Документация

Хороший обзор архитектуры системы, связанной с публикацией, можно найти здесь: http://docs.craftercms.org/en/3.0/developers/architecture.html

Хорошая статья, объясняющая рабочий процесс DevOps/Git, находится здесь: http://docs.craftercms.org/en/3.0/developers/developer-workflow.html

Обновление на основе расширенного вопроса

Мое новое понимание, основанное на вашем вопросе, таково: вы не можете разрешить развертывателям в Delivery доступ к репозиторию Authoring published для опроса из-за некоторых ограничений (даже через SSH и даже с ограничениями на исходный IP). Вы хотели бы использовать GitLab в качестве хранилища контента, доступного как push из Authoring и pull из Delivery.

Если мое понимание правильное, я могу думать о двух непосредственных решениях.

  1. Настройте задание cron в авторинге для периодической отправки в GitLab. Вам нужно будет добавить GitLab в качестве удаленного репозитория в published, а затем настроить cron следующим образом:

* * * * * git --git-dir /opt/crafter/data/repos/sites/{YOUR_SITE}/published/.git push 2>&1

Сначала проверьте это вручную, а затем cron.

  1. Напишите обработчик развертывания, который может отправлять контент в конечную точку после изменения, или дождитесь билета: https://github.com/craftercms/craftercms/issues/2017. Как только это будет создано, вам нужно будет настроить другой деплойер в Authoring, который будет отправлять в GitLab.

В любом случае, не обновляйте GitLab, так как вы используете published, а не sandbox. (См. примечания DevOps выше, чтобы узнать, почему.)

person sumerz    schedule 26.03.2018
comment
Я так не думаю. Я расширил вопрос деталями развертывания, чтобы избежать путаницы с настройкой разработки. Я уже прочитал документацию, на которую вы ссылаетесь. Документ об архитектуре особенно ничего не говорит о том, как опубликованные изменения переходят от авторства к (возможно, многим) экземплярам доставки. Мои знания о процессе публикации исходят в основном из исходного кода. К сожалению, мне все еще не хватает некоторых частей, чтобы получить правильную картину. - person Maros Ivanco; 04.04.2018
comment
Теперь, когда вы предоставили диаграмму и примечания, я лучше понимаю проблему. Я обновил свой ответ выше, чтобы, надеюсь, помочь. Несколько разработчиков Crafter зависают в IRC: freenode.net #craftercms, если у вас есть более сложные/конкретные вопросы, вам будет проще общаться там. - person sumerz; 05.04.2018
comment
Я также должен отметить, что опубликованные изменения поступают в репозиторий published, а затем их извлекают деплойнеры. У вас может быть неограниченное количество узлов доставки с деплойерами, получающими данные из published (или, в вашем случае, из GitLab, синхронизированного с published). - person sumerz; 05.04.2018
comment
Моя общая цель — разбить крафтер на несколько образов. Я хочу придерживаться 1 процесса на стратегию контейнера. Отсюда мое нежелание обслуживать git или настраивать задание cron (предложение 1). Я только что реализовал GitPushProcessor (как в предложении 2), но вместо запуска отдельного развертывателя я добавил новую цель в существующий развертыватель. Подробнее см. в решении. PushProcessor PR уже в пути. - person Maros Ivanco; 17.04.2018