CI/CD Pipeline Components

Get started

Create a new project with 2 file.

A Containerfile:

FROM alpine

A GitLab pipeline file .gitlab-ci.yml:

include:
- component: gitlab.com/xrow-public/ci-tools/common@main
- component: gitlab.com/xrow-public/ci-tools/container@main
  inputs:
    name: myapplication
    path: .

Now look the results from the pipeline builds. A new container has been pushed to the GitLab registry.

Common pipeline stages

The following stages are implemented by default:

Name	Description
.pre	default pre pipeline stage in GitLab used by some helper tasks
lint	Linting stage for all linting jobs before build
build	Build stage for all software builds
test	Test stage to validate all software builds
deploy	Deploy stage to ship a build to environments
.post	default post pipeline stage in GitLab used by some helper tasks

How components are used?

All components are in the folder templates. Each individual pipeline reuses some parts of the components. Components are used with the GitLab include keyword as documented in the GitLab Component documentation.

Example:

include:
- component: gitlab.com/xrow-public/ci-tools/common@main
- component: gitlab.com/xrow-public/ci-tools/container@main
  inputs:
    name: myapplication
    path: .

Common variables

Some pipelines require GitLab variables

Name	Default value	Required	Encoding	Description	Jobs related
CI_DEBUG_TRACE	unset	no	boolean	Enables debug mode verbose output and credentials	All pipelines
KUBECONFIG	unset	yes	file or text(base64)	Credentials to the Kubernetes clusters	All jobs that interact with Kubernetes
GITLAB_TOKEN	null	yes	text	Credentials with access to GitLab API for changelog access	All mkdocs, semantic-release component

Usage of a pipeline

Include the latest pipeline like s2i-php

include:
- component: gitlab.com/xrow-public/ci-tools/common@main
- component: gitlab.com/xrow-public/ci-tools/s2i@main
  inputs:
    name: myapplication
    type: php
    path: .

Available Pipelines

Name	Pipeline File	Example Project
Generic S2I for HTML, JAVA, NODEJS, PHP, PYTHON, ...	templates/s2i/template.yml	---
Container	templates/container/template.yml	---
Helm	templates/helm/template.yml	---
Review	templates/review/template.yml	---
Cypress	templates/cypress/template.yml	---
PHP S2i	templates/s2i-php/template.yml	---

Review apps

Git Lab Review apps are currently available for all pipelines.

You can start a review app from a merge context as well as from any stable branch. There are two jobs that control the state of a review app. review:start and review:stop. To start a review press the review:start job in your pipeline. The testing instance will be available about 15 minutes later. You will also find a list of current running review apps and review URLs under project->deployments->environments in GitLab.

Nesting components in new components

Example for a new nodejs-18 component

spec:
  inputs:
    name: 
      default: myapplication
    image:
      default: registry.access.redhat.com/ubi9/nodejs-18:1-45
---

include:
- component: gitlab.com/xrow-public/ci-tools/common@main
- component: gitlab.com/xrow-public/ci-tools/s2i@main
  inputs:
    name: $[[ inputs.name ]]
    type: nodejs
    image: $[[ inputs.image ]]

# Continue with custom code

How semantic-release and tagging works with component helm and container or buildah

Given you have a helm chart and a container pipeline.

include:
- component: gitlab.com/xrow-public/ci-tools/common@main
- component: gitlab.com/xrow-public/ci-tools/container@main
  inputs:
    name: mycontainer
- component: gitlab.com/xrow-public/ci-tools/helm@main
- component: gitlab.com/xrow-public/ci-tools/semantic-release@main

The helm chart is configured by the setting 0.0.0 and main to indicate the existence of automatic versioning.

apiVersion: v2
name: test
description: A Helm chart for Kubernetes
type: application
version: 0.0.0
appVersion: main

By default the containers are tagged according the following table

Branch	Tagged	Resulting Tags
main	yes	x.x.x (SemVer tag), latest, main, main.<commit_hash>
main	no	main, main.<commit_hash>
merge request branch	no	<commit_hash>
other-branch	yes	x.x.x (SemVer tag), other-branch, other-branch.<commit_hash>
other-branch	no	other-branch, other-branch.<commit_hash>

By default the helm are tagged according the following table. Because helm only allows SemVer. The appVersion from the Chart.yaml is the resulting tag from the container context.

Branch	Tagged	Resulting Tags
main	yes	x.x.x (SemVer tag), 0.0.0 ( meaning latest stable )
main	no	main, 0.0.0+main, 0.0.0+main.<commit_hash_short>
merge request branch	no	0.0.0+<commit_hash_short>
other-branch	yes	x.x.x (SemVer tag), other-branch+<commit_hash_short>, 0.0.0+other-branch
other-branch	no	other-branch.<commit_hash_short>, 0.0.0+other-branch

Additional helm hints

Given a values.yaml and the Chart.yaml above Bitnami common chart will inject the proper tag from the appVersion into your resulting container URI.

{{ include "common.images.image" ( dict "imageRoot" .Values.image "global" .Values.global "chart" .Chart ) }}

image:
  repository: path/to/image
  tag: ""

Given you desire in certain places in the current chart or container tags you can user the magic env variables CI_CONTAINER_RELEASE_TAG or CI_HELM_RELEASE_TAG.

image:
  repository: path/to/image
  tag: main.a5c9b61a016c50afb14288a59f49ae3a5737e528

apiVersion: v2
name: test
description: A Helm chart for Kubernetes
type: application
version: 0.0.0
appVersion: main.a5c9b61a016c50afb14288a59f49ae3a5737e528