Skip to main content

Kubernetes Operator Pipeline Template

The k8s-operator.yml pipeline template provides a CI/CD workflow for building and releasing the Welance Kubernetes Operator.

Overview​

This template orchestrates the build and release lifecycle for the Welance Kubernetes Operator, including:

  • Docker image building
  • Version validation
  • Release management
  • GitLab release creation

Note: This pipeline focuses on building and releasing the operator image. Actual Kubernetes deployment may be handled separately or through other mechanisms.

Usage​

include:
  - project: 'welance/platform/pipelines/templates/pipeline/git-flow'
    ref: release/1.0.0
    file: 'k8s-operator.yml'
variables:
  PRODUCTION_TARGET: 'welance'

Pipeline Stages​

The Kubernetes Operator pipeline template includes the following stages:

  1. init - Version validation and preparation
  2. build - Docker image building
  3. release - Release tagging and GitLab release creation

Note: This pipeline does not include a deploy stage. The operator deployment is handled separately.

Included Job Templates​

The template includes the following job templates from the ci-jobs repository:

Build Jobs​

  • build/docker-build.yml - Docker image building

Configuration Jobs​

  • config/deploy_config.yml - Infrastructure configuration (if needed)

Deploy Jobs​

  • deploy/k8s-deploy.yml - Kubernetes deployment jobs (available but not used in this pipeline)

Release Jobs​

  • release/merge-and-tag.yml - Merge request handling and tagging

Default Variables​

variables:
  CI_ARTIFACT_TOKEN: $CI_ARTIFACT_PULL_TOKEN
  REGISTRY_ID: 4495833
  DEV_TARGET: 'welance'
  STAGING_TARGET: 'welance'
  PRODUCTION_TARGET: 'welance'

Variable Details​

  • CI_ARTIFACT_TOKEN: Token for pulling artifacts from other jobs
  • REGISTRY_ID: Container registry project ID
  • DEV_TARGET: Deployment target for develop environment (default: welance)
  • STAGING_TARGET: Deployment target for staging environment (default: welance)
  • PRODUCTION_TARGET: Deployment target for production environment (default: welance, must be welance for release jobs)

Continuous Integration Workflow​

Build Jobs​

build_staging_job​

  • Stage: build
  • Extends: .docker-build
  • Needs: check_test, npm_build (optional), composer_build (optional)
  • Environment: staging
  • Runs on: release/* and hotfix/* branches
  • Artifacts: helm-chart/
  • Purpose: Builds operator Docker image for staging

build_production_job​

  • Stage: build
  • Extends: .docker-build
  • Needs: check_prod, npm_build (optional), composer_build (optional)
  • Environment: production
  • Runs on: MRs targeting main branch
  • Artifacts: helm-chart/, pipeline.env
  • Purpose: Builds operator Docker image for production

Optional Build Dependencies​

Both build jobs support optional dependencies:

  • npm_build (optional) - If the operator includes Node.js components
  • composer_build (optional) - If the operator includes PHP components

These are marked as optional: true, so the pipeline will continue even if these jobs don't exist.

Continuous Delivery Workflow​

Version Validation​

check_test​

  • Stage: init
  • Purpose: Validates semantic versioning for staging builds
  • Runs on: release/* and hotfix/* branches
  • Output: Sets VERSION={RELEASE}.rc{CI_PIPELINE_IID} (e.g., 1.0.0.rc42)

check_prod​

  • Stage: init
  • Purpose: Validates semantic versioning for production builds
  • Runs on: MRs targeting main branch
  • Output: Sets VERSION={RELEASE}, TAG=v{VERSION}, EXTRA_DESCRIPTION

Release Jobs​

merge_and_tag​

  • Stage: release
  • Extends: .merge_and_tag_job
  • Runs on: MRs targeting main (when PRODUCTION_TARGET == "welance")
  • When: manual
  • Purpose: Merges MR, creates realign branch, creates alignment MR

release_job​

  • Stage: release
  • Image: registry.gitlab.com/gitlab-org/release-cli:latest
  • Needs: merge_and_tag
  • Runs on: MRs targeting main (when PRODUCTION_TARGET == "welance")
  • Purpose: Creates GitLab release with tag and description

Required Variables​

  • STORAGE_USER_ID - User ID for storage permissions (used in Docker build)

Optional Variables​

  • PRODUCTION_TARGET - Must be set to 'welance' for release jobs to execute

Example Configuration​

include:
  - project: 'welance/platform/pipelines/templates/pipeline/git-flow'
    ref: release/1.0.0
    file: 'k8s-operator.yml'
variables:
  PRODUCTION_TARGET: 'welance'
  STORAGE_USER_ID: '1000'

Branch Strategy​

  • release/{version} - Builds operator image with staging version ({version}.rc{CI_PIPELINE_IID})
  • hotfix/{version} - Builds operator image with staging version ({version}.rc{CI_PIPELINE_IID})
  • main (via MR) - Builds operator image with production version ({version}), creates release (manual)

Version Tagging​

  • Staging: `{RELEASE}.rc{CI_PIPELINE_IID}` (e.g., 1.0.0.rc42)
  • Production: `{RELEASE}` (e.g., 1.0.0)

The operator image is tagged as: {CI_REGISTRY_IMAGE}:{VERSION}

Workflow​

Staging Workflow (release/* or hotfix/* branches)​

  1. Version Validation: check_test validates SemVer and sets `VERSION={RELEASE}.rc{CI_PIPELINE_IID}`
  2. Build Image: build_staging_job builds operator Docker image
  3. Tag & Push: Image is tagged and pushed to registry

Production Workflow (MR → main)​

  1. Version Validation: check_prod validates SemVer and sets VERSION={RELEASE}, TAG=v{VERSION}
  2. Build Image: build_production_job builds operator Docker image
  3. Tag & Push: Image is tagged and pushed to registry
  4. Merge & Tag: merge_and_tag merges MR and creates Git tags (manual)
  5. Release: release_job creates GitLab release (automatic after merge_and_tag)

Differences from Other Pipelines​

  • No Deploy Stage: This pipeline does not include deployment jobs. The operator deployment is handled separately (possibly manually or through a different process)
  • No Develop Environment: Only staging and production builds are included
  • Simpler Structure: Focuses on building and releasing the operator image
  • Targets main Branch: Uses main instead of master for production

Operator Deployment​

The operator deployment is not handled by this pipeline. After the operator image is built and released, deployment typically occurs through:

  • Manual Helm chart installation
  • Separate deployment pipeline
  • GitOps workflow (if configured separately)
  • Operator lifecycle management tools

Prerequisites​

  • Dockerfile: Project must have a Dockerfile for building the operator image
  • Semantic Versioning: Branch names must follow release/{version} or hotfix/{version} format
  • Container Registry: GitLab Container Registry must be enabled
  • PRODUCTION_TARGET: Must be set to 'welance' for release jobs

Notes​

  • The pipeline builds the operator image but does not deploy it
  • Optional npm_build and composer_build jobs allow flexibility for operators with additional components
  • Staging builds use release candidate versions (`.rc{CI_PIPELINE_IID}`)
  • Production builds use exact version from branch name
  • Release jobs only run when PRODUCTION_TARGET == "welance"
  • The pipeline targets main branch (not master) for production
  • The merge_and_tag job creates realign branches for keeping develop in sync
  • Release jobs create GitLab releases with links to container images
  • Helm charts are included in artifacts but deployment is handled separately