Now, I would expect, that I can see my changes in the remote repo. But all I can see are the initial commits from the 2. step above. No new content type, no new page, no branch "live". (The content items are however visible in the local repo)
What is missing?
Edit: Since Creafter can by set up in many ways, in order to clarify my deployment scenario, I am adding deployment diagram + short description.
There are 3 hosts - one for each environment + shared git repo.
Authoring
This is where studio is located and content authors make changes. Each change is saved to the sandbox
local git repository. When a content is published, the changes are pulled to the published
local git repository. These two local repos are not accessible from other hosts.
Delivery
This is what provides published content to the end user/application.
Deployer
is responsible for getting new publications to the delivery instance. It does so by polling (periodically pulling from) specific git repository. When it pulls new changes, it updates the local git repository site
, and Solr
indexes.
Gitlab
This hosts git repository site
. It is accessible from both - Authoring and Delivery hosts. After its creation, the new site
is pushed to this repo. The repo is also polled for new changes by Deployers
of Delivery instances.
In order for this setup to work, the published changes must somehow end up in Gitlab's site
repo, but they do not (the red communication path from Authoring Deployer
to the Gitlab's site
)
I implemented GitPushProcessor
and configured new deployment target in authoring Deployer
, adding mysite-live.yaml
to /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
I think you might have confused push
with publish
.
Authoring (Studio) publishes to Delivery (Engine) after an approval workflow that makes content go live. Authoring is where content (and code if you like) is managed and previewed safely, then that is published to the live delivery nodes for delivery to the end-user.
A site's local git repository can be pushed/pulled to/from remote repositories. This means:
When code flows forward from a developer to Studio, that's when Studio pulls from the remote git repo.
When content flows backward from Studio to the developer, that's when Studio pushes to the remote git repo.
A good bird's eye view of the architecture of the system relating to publishing can be found here: http://docs.craftercms.org/en/3.0/developers/architecture.html
A good article that explains the DevOps workflow/Git stuff is here: http://docs.craftercms.org/en/3.0/developers/developer-workflow.html
My new understanding based on your question is: You can't allow the deployers in Delivery to access Authoring's published
repo to poll due to some constraint (even over SSH and even with limits on the source IP). You'd like to use GitLab as a form of content depot that's accessible as a push
from Authoring and pull
from Delivery.
If my understanding is correct, I can think of two immediate solutions.
published
and then set up a cron like this:* * * * * git --git-dir /opt/crafter/data/repos/sites/{YOUR_SITE}/published/.git push 2>&1
Test it out by hand first, then cron it.
In either case, beware not to update things in GitLab since you're using published
and not sandbox
. (See DevOps notes above to learn why.)