How to Deploy in Your Infrastructure¶

This page explains how to take possession of a Welma delivery and deploy it in your infrastructure.

First you need to retrieve the delivered Welma layers and components:

meta-welma
welma-bootflags
welma-manifest
welma-test
ci (optional)
meta-cvescan (optional)
pluma-lats (optional)

Push each of them to your Git server (eg: Gitlab).

Edit URI¶

Then you need to update some URI to match your infrastructure:

In welma-manifest, create you own manifest file, with your URI.

# NAME                URI                                              REF
poky                  git://git.yoctoproject.org/poky                  kirkstone-4.0.7
meta-openembedded     git://git.openembedded.org/meta-openembedded     278ec081a64e6a7679d6def550101158126cd935
meta-welma            <your-base-uri>/meta-welma                       kirkstone-next
meta-demo-headless    <your-base-uri>/meta-demo-headless               kirkstone-next
welma-test            <your-base-uri>/welma-test                       kirkstone-next
...

In local.conf, either:
- Set:
  - WELMA_GIT_URI_BASE (used to fetch some Welma components, typically bootflags).
  - WELMA_MSC_GIT_URI_BASE (used by meta-welma-sm2s-imx8 to fetch MSC-related components such as u-boot-imx-msc, linux-imx-msc, ...).
- Or set PREMIRRORS to redirect to your servers. Example:
```
PREMIRRORS:append = " git://.*gitlab.com/witekio/.* git://<user>@<your-server>/<your-path>/BASENAME"
```
In ci set up the following job variables:
- WELMA_MANIFEST_GIT_URI
- WELMA_MANIFEST_GIT_REF
- WELMA_MANIFEST_FILE
- META_CVESCAN_GIT_URI (optional)
- META_CVESCAN_GIT_REF (optional)
- CVESCAN_GIT_URI (optional)
- CVESCAN_GIT_REF (optional)
- PLUMA_PIP_URI (optional)
- PLUMA_LATS_GIT_URI (optional)
- PLUMA_LATS_GIT_REF (optional)
- where:
  - _GIT_REF can either be git commit identifiers, branches or tags.
  - _GIT_URI must be in a format supported by git.
  - _PIP_URI must be in a format supported by pip.

These variables are used by the snippets of welma.yml and must be set in your jobs descriptions (typically in .gitlab-ci.yml).