Light Module deployment
Your light module project must contain a light-modules
folder containing one or more light modules.
The .gitlab-ci.yml will break if there are no light modules in the light module project.
|
The example .gitlab-ci.yml does not contain the JavaScript build commands.
|
Light module structure example
custom-lightmodule
|-- README.md
|-- .gitlab-ci.yml
|-- light-modules
|-- custom-lightmodule
|-- README.md
|-- decorations
|-- dialogs
| |-- components
| |-- pages
| |-- custom-page.yaml
|-- i18n
| |-- custom-lightmodule-messages_en.properties
|-- includes
| |-- README.txt
|-- templates
| |-- components
| |-- pages
| |-- custom-page.ftl
| |-- custom-page.yaml
|-- webresources
The .gitlab-ci.yml
file
It’s important that you configure the .gitlab-ci.yml
file correctly so that your light development changes are picked up and deployed.
Magnolia automatically picks up the changes when using this approach. |
gitlab-ci.yml
stages:
- deploy (1)
deploy:integration:sync:
stage: deploy
image: devspacesh/devspace:5
cache:
# We need this for syncing light modules into multiple pods.
key: podlist-$CI_COMMIT_REF_SLUG
paths:
- pods.txt
policy: pull
environment:
name: dev (2)
before_script:
- export KUBECTL_NAMESPACE=${CI_ENVIRONMENT_SLUG} (3)
- export LIGHT_MODULES_CONTAINER_PATH=/mgnl-home/modules
- export KUBECONFIG=$KUBE_CONFIG (4)
script:
- kubectl -n $KUBECTL_NAMESPACE get pods -l "release=$KUBECTL_NAMESPACE,tier=app" -o name | sed 's/^pod\///' > pods.txt
- >
for pod in `cat pods.txt`; do
devspace sync -n $KUBECTL_NAMESPACE --local-path light-modules/ --pod $pod -c $KUBECTL_NAMESPACE --container-path=$LIGHT_MODULES_CONTAINER_PATH --initial-sync mirrorLocal --no-watch --upload-only
done
when: manual (5)
1 | The deploy stage first collects all pods running author or public instances and uses the devspace tool to rsync light module files to the running pods. |
2 | The environment name corresponds to the environment scope (dev or prod ) defined in the Deployments section. In different environments the same variable names can be used. |
3 | The namespace must be the same the corresponding Magnolia deployment is running in. |
4 | The KUBE_CONFIG CI/CD variable should be defined as type File and hold KubeConfig of the cluster the deployment should go to. The same variable can be defined in different environment scopes (see 2 ) |
5 | The deployment must be triggered manually. |