Using GitLab as a Git provider with your supply chains

This topic describes how to use GitLab as a Git provider with your Supply Chain Choreographer supply chains.

Overview

There are two uses for Git in a supply chain:

• As a source of code to build and deploy applications
• As a repository of configuration created by the build cluster which is deployed on a run or production cluster

Using GitLab as a repository for committed code

This section tells you how developers can use GitLab to commit source code to a repository that the supply chain pulls.

GitLab example

The following example uses the GitLab source repository:

https://gitlab.example.com/my-org/repository.git

You can configure the supply chain by using tap-values.yaml:

ootb_supply_chain_testing_scanning:
  git_implementation: go-git

or by using a workload parameter:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  ...
spec:
  params:
    - name: gitImplementation
      value: go-git

Using GitLab as a GitOps repository

The supply chain commits Kubernetes configuration to a Git repository. This configuration is then applied to another cluster. This is the GitOps promotion process.

You must construct a path and configure your Git implementation to read and write to an GitLab repository.

GitOps write path example

The following example uses the GitLab Git repository:

https://gitlab.example.com/my-org/repository.git

1. Set the gitops_server_kind workload parameters to gitlab.

     apiVersion: carto.run/v1alpha1
     kind: Workload
     metadata:
       ...
     spec:
       params:
         - name: gitops_server_kind
           value: gitlab
         ...
   

2. Set other GitOps values in either tap-values.yaml or in the workload parameters. By using tap-values.yaml:

       ootb_supply_chain_testing_scanning:
         gitops:
           server_address: https://gitlab.example.com
           repository_owner: my-org
           repository_name: repository
   

   By using the workload parameters:

       apiVersion: carto.run/v1alpha1
       kind: Workload
       metadata:
         ...
       spec:
         params:
           - name: gitops_server_address
             value: https://gitlab.example.com
           - name: gitops_repository_owner
             value: my-org
           - name: gitops_repository_name
             value: repository
           ...
   

GitLab read example

The following example uses the GitLab repository:

https://gitlab.example.com/my-org/repository.git

You can configure the delivery tap-values.yaml:

ootb_delivery_basic:
  git_implementation: go-git

or the deliverable parameter:

apiVersion: carto.run/v1alpha1
kind: Deliverable
metadata:
  ...
spec:
  params:
    - name: gitImplementation
      value: go-git

GitLab over HTTPS with a custom CA certificate

When using HTTPS with a custom certificate authority, you must configure the Git secret both in tap-values.yaml and the Git secret used by the GitRepository.

1. Set the shared.ca_cert_data in tap-values.yaml. You must set the Git secret in the caFile field.

     apiVersion: v1
     kind: Secret
     metadata:
       name: SECRET-NAME
       annotations:
         tekton.dev/git-0: GIT-SERVER        # ! required
     type: kubernetes.io/basic-auth          # ! required
     stringData:
       username: GIT-USERNAME
       password: GIT-PASSWORD
       caFile: |
       -----BEGIN CERTIFICATE-----
       ...
       -----END CERTIFICATE-----
   

2. Associate the secret with the ServiceAccount.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: default
   secrets:
     - name: registry-credentials
     - name: tap-registry
     - name: GIT-SECRET-NAME
   imagePullSecrets:
     - name: registry-credentials
     - name: tap-registry
   

For information about authentication, see Git Authentication.