现在,我希望,我可以在远程仓库中看到我的变化。但我能看到的只是上面第2步的初始提交。没有新的内容类型,没有新的页面,没有分支“直播”。 (但是内容项在本地仓库中可见)
缺少什么?
修改 由于Creafter可以通过多种方式设置,为了阐明我的部署方案,我正在添加部署图+简短描述。
创作
这就是工作室的位置,内容作者会做出改变。每个更改都保存到sandbox
本地git存储库。发布内容时,更改将被拉到published
本地git存储库。这两个本地回购广告无法访问来自其他主机。
递送
这是向最终用户/应用程序提供已发布内容的原因。
Deployer
负责将新出版物发送到交付实例。它通过轮询(定期从中拉出)特定的git存储库来实现。当它进行新的更改时,它会更新本地git存储库site
和Solr
索引。
Gitlab
这将托管git存储库site
。它可以从site
被推送到此回购。还会通过Deployers
传递实例对存储库中的新更改进行轮询。
为了使这个设置起作用,发布的更改必须以某种方式结束于Gitlab的site
repo,但它们不会(从Authoring Deployer
到Gitlab的{{1}的红色通信路径) })
我实施了site
并在编写GitPushProcessor
时配置了新的部署目标,并将Deployer
添加到mysite-live.yaml
:
/opt/crafter-cms-authoring/data/deployer/target/
答案 0 :(得分:3)
我认为您可能会将push
与publish
混淆。
创作(Studio)在使内容生效的批准工作流程之后发布到交付(引擎)。创作是安全地管理和预览内容(以及您喜欢的代码),然后发布到实时传送节点以便传送给最终用户。
可以向/从远程存储库推送/拉出站点的本地git存储库。这意味着:
当代码从开发人员流向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
访问。
如果我的理解是正确的,我可以想到两个直接的解决方案。
published
中将GitLab添加为远程仓库,然后设置这样的cron: * * * * * git --git-dir /opt/crafter/data/repos/sites/{YOUR_SITE}/published/.git push 2>&1
首先用手测试,然后用手测试。
在任何一种情况下,请注意不要更新GitLab中的内容,因为您使用的是published
而不是sandbox
。 (请参阅上面的DevOps说明以了解原因。)