TBC Kicker - GitLab CI/CD Configuration Wizard

This skill guides users through generating .gitlab-ci.yml files using the To-Be-Continuous (TBC) framework, replicating the exact workflow of the Kicker web wizard.

Overview

TBC Kicker is an interactive 8-step wizard that generates GitLab CI/CD configurations by combining 50 modular templates across 8 categories:

Category	Count	Selection	Description
Build	15	Single	Programming language/framework
Code Analysis	7	Multiple	Security, linting, SAST
Packaging	3	Single	Container/package builds
Infrastructure	1	Single	Terraform IaC
Deployment	11	Single	Cloud/K8s deployment
Acceptance	10	Multiple	E2E/API testing
Other	3	Multiple	Misc utilities

Wizard Workflow

Step 0: Configure Global Options

Before template selection, configure these options:

Configuration Mode

• Basic: Show only essential variables
• Advanced: Show all configuration variables including advanced ones

Include Mode

Mode	Syntax	Use Case
component	$CI_SERVER_FQDN/path/template@version	GitLab 16.0+ (recommended)
project	project: "path" + ref + file	Self-hosted GitLab
remote	https://host/path/-/raw/version/file	External GitLab

Version Mode

Mode	Example	Updates	Stability
major	@7	Auto major	Least stable
minor	@7.5	Auto patch	Recommended
full	@7.5.2	None	Most stable

Additional Options

• With stages: Include custom stages section
• GitLab Host: Custom host for remote mode

Step 1: Build (Language)

Select ONE build template or "none":

Template	Prefix	Description
Angular	NG_	Angular CLI projects
Bash	BASH_	Shell scripts with ShellCheck/Bats
DBT	DBT_	Data Build Tool
GitLab Package	GLPKG_	Generic package publishing
Go	GO_	Golang applications
Gradle	GRADLE_	Java/Kotlin with Gradle
GNU Make	MAKE_	Makefile-based builds
Maven	MAVEN_	Java with Maven
MkDocs	MKD_	Documentation sites
Node.js	NODE_	npm/yarn/pnpm projects
PHP	PHP_	PHP with Composer
pre-commit	PRE_COMMIT_	Pre-commit hooks
Python	PYTHON_	Python with pip/poetry
Scala/SBT	SBT_	Scala applications
Sphinx	SPHINX_	Sphinx documentation

Step 2: Code Analysis

Select MULTIPLE analysis templates:

Template	Prefix	Description
DefectDojo	DEFECTDOJO_	Security report aggregation
Dependency Track	DEPTRACK_	SBOM & vulnerability tracking
Gitleaks	GITLEAKS_	Secret detection
MobSF	MOBSF_	Mobile security
SonarQube	SONAR_	Code quality & security
Spectral	SPECTRAL_	OpenAPI/AsyncAPI linting
SQLFluff	SQLFLUFF_	SQL linting

Step 3: Packaging

Select ONE packaging template or "none":

Template	Prefix	Description
Cloud Native Buildpacks	CNB_	Paketo buildpacks
Docker	DOCKER_	Dockerfile builds (kaniko/buildah/dind)
Source-to-Image	S2I_	OpenShift S2I

Step 4: Infrastructure

Select ONE infrastructure template or "none":

Template	Prefix	Description
Terraform	TF_	Infrastructure as Code

Step 5: Deployment

Select ONE deployment template or "none":

Template	Prefix	Description
Ansible	ANSIBLE_	Configuration management
AWS	AWS_	Amazon Web Services
Azure	AZURE_	Microsoft Azure
Cloud Foundry	CF_	Cloud Foundry PaaS
Docker Compose	DCMP_	Docker Compose/Stack
Google Cloud	GCLOUD_	Google Cloud Platform
Helm	HELM_	Kubernetes Helm charts
Helmfile	HELMFILE_	Helmfile deployments
Kubernetes	K8S_	kubectl deployments
OpenShift	OS_	OpenShift deployments
S3	S3_	S3-compatible storage

Step 6: Acceptance Tests

Select MULTIPLE acceptance test templates:

Template	Prefix	Description
Bruno	BRUNO_	API testing
Cypress	CYPRESS_	E2E web testing
Hurl	HURL_	HTTP testing
k6	K6_	Load testing
Lighthouse	LHCI_	Performance testing
Playwright	PLAYWRIGHT_	E2E testing
Postman	POSTMAN_	API testing
Puppeteer	PUPPETEER_	Browser automation
Robot Framework	ROBOT_	Test automation
TestSSL	TESTSSL_	TLS/SSL testing

Step 7: Other Templates

Select MULTIPLE utility templates:

Template	Prefix	Description
GitLab Butler	BUTLER_	Project cleanup
Renovate	RENOVATE_	Dependency updates
Semantic Release	SEMREL_	Version management

Step 8: Generate Configuration

Generate the .gitlab-ci.yml with selected templates.

Template Configuration

Variables

Each template has variables with these properties:

Property	Description
name	Variable name (e.g., PYTHON_IMAGE)
default	Default value
type	text, url, boolean, enum, number
mandatory	Required to use template
secret	Store in CI/CD settings, not in file
advanced	Only show in advanced mode

Features

Templates have toggleable features:

# Feature enabled by default - disable with:
inputs:
  lint-disabled: true

# Feature disabled by default - enable with:
inputs:
  publish-enabled: true

Variants

Templates may have variants for additional functionality:

Variant	Available In	Purpose
Vault	Most templates	HashiCorp Vault secrets
OIDC	AWS, Azure, GCP	OpenID Connect auth
Google Cloud	Ansible, Python, Helm, K8s, Terraform	GCP authentication
AWS	Python, Terraform	AWS authentication
GitLab Pages	MkDocs, Sphinx, DBT	Publish to GitLab Pages
Jib	Maven	Build Docker images with Jib

YAML Output Format

Component Mode (Recommended)

include:
  # Python template
  - component: $CI_SERVER_FQDN/to-be-continuous/python/python@7
    inputs:
      image: "python:3.12-slim"
      build-system: "poetry"
      pytest-enabled: true
      bandit-enabled: true

  # Python template (Vault variant)
  - component: $CI_SERVER_FQDN/to-be-continuous/python/python-vault@7
    inputs:
      vault-base-url: "https://vault.example.com"

# secret variables
# (define the variables below in your GitLab group/project variables)
# VAULT_ROLE_ID: The AppRole RoleID
# VAULT_SECRET_ID: The AppRole SecretID

Project Mode

include:
  # Python template
  - project: "to-be-continuous/python"
    ref: "7.5"
    file: "templates/gitlab-ci-python.yml"

# secret variables
# SONAR_TOKEN: SonarQube authentication token

variables:
  PYTHON_IMAGE: "python:3.12-slim"
  PYTHON_BUILD_SYSTEM: "poetry"
  PYTEST_ENABLED: "true"

Remote Mode

include:
  # Python template
  - remote: "https://gitlab.com/to-be-continuous/python/-/raw/7.5/templates/gitlab-ci-python.yml"

variables:
  PYTHON_IMAGE: "python:3.12-slim"

Input Name Transformation

For component mode, transform variable names:

1. Strip prefix: PYTHON_IMAGE → IMAGE
2. Lowercase: IMAGE → image
3. Hyphens for underscores: BUILD_SYSTEM → build-system

Examples:

• PYTHON_IMAGE → image
• PYTHON_BUILD_SYSTEM → build-system
• PYTEST_ENABLED → pytest-enabled
• GO_CI_LINT_DISABLED → ci-lint-disabled

Stages (Optional)

stages:
  - build
  - test
  - package-build
  - package-test
  - infra
  - deploy
  - acceptance
  - publish
  - infra-prod
  - production

Environment Configuration

Deployment templates support 4 environments:

Environment	Variable Prefix	Branch	Purpose
review	{PREFIX}_REVIEW_	Feature	Dynamic review apps
integration	{PREFIX}_INTEG_	develop	CI environment
staging	{PREFIX}_STAGING_	main	Pre-production
production	{PREFIX}_PROD_	main	Production

Presets

Pre-configured variable sets for common services:

Preset	Variables Set
SonarCloud	SONAR_HOST_URL: https://sonarcloud.io
OpenShift Sandbox	OS_URL, K8S_URL for RedHat sandbox

Additional Resources

Reference Files

For detailed template configurations:

• references/build-templates.md - All 15 build templates with full variables
• references/deployment-templates.md - 12 templates (1 infrastructure + 11 hosting) with variants
• references/analysis-templates.md - 23 templates (7 analysis + 3 packaging + 10 acceptance + 3 misc/publish)
• references/presets.md - Pre-configured settings for SonarCloud, OpenShift Sandbox

Example Files

Working configurations in examples/:

• python-docker-k8s.yml - Python + Docker + Helm
• node-sonar-docker.yml - Node.js + SonarQube + Docker
• terraform-aws.yml - Terraform + AWS with OIDC
• java-maven-cf.yml - Maven + Cloud Foundry

Official Resources

• Kicker Wizard: https://to-be-continuous.gitlab.io/kicker
• Documentation: https://to-be-continuous.gitlab.io/doc
• Templates: https://gitlab.com/to-be-continuous
• Samples: https://gitlab.com/to-be-continuous/samples

Workflow Guidelines

For New Projects

1. Ask about project type, language, and deployment target
2. Configure global options (recommend component mode, minor version)
3. Select templates for each category
4. Read schemas/{template}.json to get valid inputs, components, and versions
5. Configure variables (focus on mandatory and image versions)
6. Enable relevant features and variants
7. Generate the configuration

For Existing Projects

1. Review current .gitlab-ci.yml
2. Identify opportunities to use TBC templates
3. Read schemas/{template}.json to get valid inputs, components, and versions
4. Suggest equivalent TBC templates
5. Provide migration guidance

Best Practices

• Use component mode for GitLab 16.0+
• Use minor version for balance of updates and stability
• Enable only needed features
• Store secrets in CI/CD variables
• Document non-default configurations
• Use variants for cloud authentication (Vault, OIDC)