SCAMPI deployment must be robust, repeatable, and idempotent. We have multiple flavours of deployment for different configurations.


By running make in the command line, we can see all the targets and arguments (and their defaults) available.

[user@pc skampi]$ make
make targets:
Makefile:delete_all            delete ALL of the helm chart release
Makefile:delete                delete the helm chart release. @param: same as deploy_all, plus HELM_CHART
Makefile:delete_etcd           Remove etcd-operator from namespace
Makefile:delete_gangway        delete install gangway authentication for gitlab. @param: CLIENT_ID, CLIENT_SECRET, INGRESS_HOST, CLUSTER_NAME, API_SERVER_IP, API_SERVER_PORT
Makefile:delete_traefik        delete the helm chart for traefik. @param: EXTERNAL_IP
make vars (+defaults):        2020         $(shell echo ~/.minikube)       $(shell echo ~/.kube)
Makefile:API_SERVER_IP         $(THIS_HOST)## Api server IP of k8s

Makefile:API_SERVER_PORT       6443         # Api server port of k8s

All the next deployments are deployed using using the same makefile.


Deploy only one Helm Chart available at charts directory.

Basic arguments:

  • KUBE_NAMESPACE - integration default
  • HELM_CHART - tango-base default
make deploy KUBE_NAMESPACE=integration HELM_CHART=tmc-proto

Deploy All

Deploy every helm chart inside charts directory.

Basic parameters:

  • KUBE_NAMESPACE - integration default
make deploy_all KUBE_NAMESPACE=integration

Deploy All with Order

Deploy every helm chart inside charts directory order by its dependencies.

Basic parameters:

  • KUBE_NAMESPACE - integration default
  • DEPLOYMENT_ORDER - tango-base cbf-proto csp-proto sdp-prototype tmc-proto oet webjive archiver dsh-lmc-prototype logging skuid default
make deploy_ordered KUBE_NAMESPACE=integration


In SKAMPI, we separated the parameters into two levels. The first one can change the behaviour of the makefile, and the second level can only change the arguments in each chart.

Level 1

The first one is inside the Makefile of the repository and is the top priority meaning that it overrides all the parameters in any level below. We have three ways to customize these parameters and they are prioritize in this order (from most to last important):

  1. Command-line arguments - make deploy_ord KUBE_NAMESPACE=integration;
  2. PrivateRules.mak - Create this file and add arguments. Ex: HELM_CHART = logging;
  3. Makefile defaults - All the defaults are available by running make in the command-line.

Please note that one of the parameter at this level is the DEPLOYMENT_ORDER which allow ability to select the charts needed for a particular configuration of the deployment (the charts will be deployed in the order or this parameter).

Level 2

The second level is specified with the Values Files.

The priority file is the root directory and goes along the deploy commands with values.yaml by default but that could change using the VALUES argument in the makefile.

    enabled: false
    enabled: false
    enabled: false
    enabled: false
    enabled: false
    enabled: false

minikube: true

This root values file overrides the values.yaml file inside each chart. All chart values files can also be changed to customize your deployment needs.

In the skampi repository, there are 2 examples of values files, one that has everything enabled (pipeline.yaml) and another one with has come charts disabled (values.yaml). The latter disable the logging chart and the archiver chart and it has been thought for a minikube environment.

Please note that the two values file represent the minimum charts needed (values.yaml) for running all the fast tests (mark=fast) while the other (pipeline.yaml) is the complete deployment of SKAMPI.

Forward Oriented Deployment

With the help of the above parameter levels it is possible to customize the deployment of SKAMPI. It is very important to note that it is possible to deploy the charts incrementally (forward oriented).