如何设置创作环境将站点发布到远程git仓库?

时间:2018-03-26 12:54:34

标签: crafter-cms

  1. 我下载并开始创作环境(crafter-cms-authoring.zip)
  2. 由远程git repo支持的创建站点,如:Create site based on a blueprint then push to remote bare git repository
  3. 中所述
  4. 创建了内容类型,新页面。
  5. 发布一切
  6. 现在,我希望,我可以在远程仓库中看到我的变化。但我能看到的只是上面第2步的初始提交。没有新的内容类型,没有新的页面,没有分支“直播”。 (但是内容项在本地仓库中可见)

    缺少什么?

    修改 由于Creafter可以通过多种方式设置,为了阐明我的部署方案,我正在添加部署图+简短描述。

    headless deployment 有3个主机 - 每个环境一个+共享git repo。

    创作
    这就是工作室的位置,内容作者会做出改变。每个更改都保存到sandbox本地git存储库。发布内容时,更改将被拉到published本地git存储库。这两个本地回购广告无法访问来自其他主机。

    递送
    这是向最终用户/应用程序提供已发布内容的原因。 Deployer负责将新出版物发送到交付实例。它通过轮询(定期从中拉出)特定的git存储库来实现。当它进行新的更改时,它会更新本地git存储库siteSolr索引。

    Gitlab
    这将托管git存储库site。它可以从访问。创建后,新site被推送到此回购。还会通过Deployers传递实例对存储库中的新更改进行轮询。

    为了使这个设置起作用,发布的更改必须以某种方式结束于Gitlab的site repo,但它们不会(从Authoring Deployer到Gitlab的{{1}的红色通信路径) })

    基于@summerz答案的解决方案

    我实施了site并在编写GitPushProcessor时配置了新的部署目标,并将Deployer添加到mysite-live.yaml

    /opt/crafter-cms-authoring/data/deployer/target/

1 个答案:

答案 0 :(得分:3)

我认为您可能会将pushpublish混淆。

发布时

创作(Studio)在使内容生效的批准工作流程之后发布到交付(引擎)。创作是安全地管理和预览内容(以及您喜欢的代码),然后发布到实时传送节点以便传送给最终用户。

开启DevOps

可以向/从远程存储库推送/拉出站点的本地git存储库。这意味着:

  • 代码可以从开发人员的工作站流向Studio(通过github,gitlab,bitbucket等)< ==这是代码向前发展(并且可以通过QA,负载测试等环境流动)
  • 内容可以以类似的方式从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

根据扩展问题更新

我基于您的问题的新理解是:由于某些限制(即使通过SSH甚至限制源IP),您也不能允许交付中的部署者访问Authoring的published repo进行轮询。您希望将GitLab用作内容库的一种形式,可以从作者push和交付pull访问。

如果我的理解是正确的,我可以想到两个直接的解决方案。

  1. 在创作中设置一个cron作业,定期推送到GitLab。 您需要在published中将GitLab添加为远程仓库,然后设置这样的cron:
  2. * * * * * git --git-dir /opt/crafter/data/repos/sites/{YOUR_SITE}/published/.git push 2>&1

    首先用手测试,然后用手测试。

    1. 编写部署处理程序,可以在更改时将内容推送到终点,或者等待票证:https://github.com/craftercms/craftercms/issues/2017。 构建完成后,您需要在Authoring中配置另一个将推送到GitLab的部署者。
    2. 在任何一种情况下,请注意不要更新GitLab中的内容,因为您使用的是published而不是sandbox。 (请参阅上面的DevOps说明以了解原因。)