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.
Feedback

PaaS