Pipeline Configuration

This guideline will guide you to configure and adopt the sdo pipeline for your installed Solution Envoys. This configuration is done in GitLab.

Prerequisites

A user with complete admin access to GitLab is needed
open GitLab (see helm installation of ssob-sdo for the hostname), e.g. https://gitlab.apps.openshift-cluster.mydomain.cloud
login with root user and password

Note: The root password can be found in the secret initial-root-password, which is located in the namespace, where GitLab was installed.

Example:
```
oc -n foundation get secret \
gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 -d
                            
```

General Pipeline Configuration

During the installation of FSW a default configuration of the pipeline was done. Herein the project system/pipeline-fragments was created. This is used to configure general pipeline behaviour in interaction with GitLab CI variables.

Structure of project system/pipeline-fragments

The project consists of three folders:

custom: It contains the configuration of the available Solution Envoys and steps in the pipeline (must be adjusted)
defaults: It contains the job definitions of all generall steps (you will probably never change)
templates: It contains the job implementations (you will probably never change)

Adjust custom configuration of pipeline to define and add Solution Envoy

This default configuration has to be adjusted for your Solution Envoys:

open GitLab group system
open project pipeline-fragments
open folder custom
open and edit file deploy-solution.yml
all deploy and test steps are predefined here, including a DEV, TEST and PROD Solution Envoy. You can enable them later on.
adjust the ADO_CI_RUNTIME_NAME variable of the DEV STAGE from DEV to cpd-runtime-default for example. Please ensure that the OpenShift namespace of the Solution Envoy matches this entry.
Commit changes

Enable additional default stages

During the installation GitLab CI variables are created to manage the execution of the different stages. By default only one DEV STAGE is enabled. Enabling other stages (e.g. TEST Stage) can be done by changing the GitLab CI variables.

open group managed-solutions
open Settings -> CI/CD -> Variables and Reveal values
change value of ADO_CI_STAGE_TEST_DISABLED to FALSE for enabling TEST Stage
change value of ADO_CI_AUTOMATIC_PROD_DEPLOYMENT_DISABLED to FALSE for enabling PROD Stage

open GitLab group system
open project pipeline-fragments
open folder custom
open and edit file deploy-solution.yml
adjust the ADO_CI_RUNTIME_NAME variable of the TEST STAGE from TEST to ssob-srt-test for example. Please ensure that the OpenShift namespace of the Solution Envoy matches this entry.
adjust the ADO_CI_RUNTIME_NAME variable of the PROD STAGE from PROD to ssob-srt-prod for example. Please ensure that the OpenShift namespace of the Solution Envoy matches this entry.
Commit changes

Configure additional stages

If you have introduced completely new stages these must be added also into the stages.yml file:

open GitLab group system
open project pipeline-fragments
open folder custom
open and edit file stages.yml
add the deploy-dev2 stage into the list of stages (the order is important)
Commit changes

open GitLab group system
open project pipeline-fragments
open folder custom
open and edit file deploy-solution.yml
add completely new stages by copying e.g. the DEPLOY Stage DEV
- adjust the stage setting
- adjust the ADO_CI_RUNTIME_NAME
Example:
```
stage: deploy-dev2
ADO_CI_RUNTIME_NAME: cpd-runtime-default2 
                    
```
Commit changes

Default CI/CD variables

The following table lists existing CI/CD variables that can be used for adjusting the pipeline:


Parameter	Enables or Disables	Allowed values
`ADO_CI_APPROVAL_DISABLED`	Manual approval before the prod stage	`TRUE` or `FALSE`
`ADO_CI_AUTOMATIC_PROD_DEPLOYMENT_DISABLED`	Automatic prod deployment	`TRUE` or `FALSE`
`ADO_CI_MANUAL_PROD_DEPLOYMENT_DISABLED`	Manual prod deployment, means the steps to deploy on prod environment are displayed but not executed	`TRUE` or `FALSE`
`ADO_CI_SEMAPHORE_DISABLED`	Allows only one deployment in parallel, helpful if many people are working on one solution (see Enable Semaphore step)	`TRUE` or `FALSE`
`ADO_CI_STAGE_TEST_DISABLED`	Deployment and test of test stage	`TRUE` or `FALSE`
`ADO_CONFIG_MANAGEMENT_CA_FILE`	Installs provided certificate to pipeline docker images	String
`ADO_KEYCLOAK_CA_FILE`	Installs provided certificate to pipeline docker images	String
`OPENSHIFT_SERVICE_CA_FILE`	Installs provided certificate to pipeline docker images	String
`KUBERNETES_CA_FILE`	Installs provided certificate to pipeline docker images	String
`ADO_CONFIG_MANAGEMENT_INTERNAL_COMMUNICATION`	Defines if internal service or external base host should be used to get configurations from configuration-management	`TRUE` or `FALSE`

Enable Semaphore step

The semaphore step ensures that the first deploy step can only be started if no other pipeline has been started before, otherwise it will wait until the leading pipeline has finished. To Enable the provided semaphore step, two additional CI/CD variables are needed on group level managed-solutions:

GITLAB_API_TOKEN: private token with admin rights (in the scope API)
CI_CD_GITLAB_URL: base url of GitLab, e.g. https://gitlab.apps.openshift-cluster.mydomain.cloud