To Be Continuous

https://to-be-continuous.gitlab.io/doc
Admin
To Be Continuous makes building professional CI/CD pipelines easy by providing modular,...
Tokens:172,086
Snippets:2,417
Trust Score:7
Update:5 months ago
Show doc for...
Tokens:
Raw
### Example of S2I Release Image Configuration

Source: https://to-be-continuous.gitlab.io/doc/ref/s2i

Illustrates how the S2I_RELEASE_IMAGE variable is configured, showing both a basic setup and one that includes the commit reference name.

```yaml
S2I_RELEASE_IMAGE: "registry.gitlab.com/$CI_PROJECT_NAME"

```

```yaml
S2I_RELEASE_IMAGE: "registry.gitlab.com/$CI_PROJECT_NAME:$CI_COMMIT_REF_NAME"

```

--------------------------------

### Maven Release Prepare Goal Example

Source: https://to-be-continuous.gitlab.io/doc/ref/maven

Example of invoking the Maven Release Plugin's prepare goal for versioning and tagging.

```bash
release:prepare
```

--------------------------------

### Jib Build Goal Example

Source: https://to-be-continuous.gitlab.io/doc/ref/maven

Example of invoking the Jib build goal using Maven.

```bash
mvn verify com.google.cloud.tools:jib-maven-plugin:build
```

--------------------------------

### Install GitLab Copy CLI

Source: https://to-be-continuous.gitlab.io/doc/self-managed/basic

Installs the GitLab Copy CLI tool. Requires Python 3.11 or higher.

```bash
pip install gitlab-cp --index-url https://gitlab.com/api/v4/projects/to-be-continuous%2Ftools%2Fgitlab-cp/packages/pypi/simple --upgrade

```

--------------------------------

### Install karma-sonarqube-execution-reporter

Source: https://to-be-continuous.gitlab.io/doc/ref/angular

Install the karma-sonarqube-execution-reporter package as a development dependency for SonarQube unit test report integration.

```bash
npm install --save-dev karma-sonarqube-execution-reporter
```

--------------------------------

### Dockerfile with Build Arguments

Source: https://to-be-continuous.gitlab.io/doc/ref/docker

Example Dockerfile demonstrating how to use ARG instructions to access variables passed via DOCKER_BUILD_ARGS.

```dockerfile
FROM scratch

ARG CI_PROJECT_URL
ARG MY_VAR
LABEL name="my-project"                   \
      description="My Project: $MY_VAR"   \
      url=$CI_PROJECT_URL                 \
      maintainer="my-project@acme.com"
```

--------------------------------

### Bats Test Script Example

Source: https://to-be-continuous.gitlab.io/doc/ref/bash

An example Bats test script demonstrating how to load libraries like bats-support and bats-assert, and define a basic test case using `run` and `assert_line`.

```bash
#!/usr/bin/env bats
load "$BATS_LIBRARIES_DIR/bats-support/load.bash"
load "$BATS_LIBRARIES_DIR/bats-assert/load.bash"

@test "test something" {
    run echo "Hello there"
    assert_line "Hello there"
}

```

--------------------------------

### Configure pyproject.toml for Setuptools

Source: https://to-be-continuous.gitlab.io/doc/ref/python

This `pyproject.toml` example configures project metadata, build system, and version management for Setuptools projects using bump-my-version.

```toml
[project]
name = "project-name"

[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[tool.bumpversion]
current_version = "0.0.0"

[[tool.bumpversion.files]]
filename = "project-name/__init__.py"

```

--------------------------------

### Install karma-junit-reporter

Source: https://to-be-continuous.gitlab.io/doc/ref/angular

Install the karma-junit-reporter package as a development dependency to generate JUnit XML reports for GitLab integration.

```bash
npm install --save-dev karma-junit-reporter
```

--------------------------------

### Configure Cypress Job Tags

Source: https://to-be-continuous.gitlab.io/doc/ref/cypress

Example of how to specify tags for Cypress jobs, recommending 'cypress-amd64' for compatibility.

```yaml
cypress:
  ...
  ...
  tags:
    - cypress-amd64

```

--------------------------------

### GitLab CI/CD Node and Vault Integration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/node

Example GitLab CI configuration including the Node.js template and the Vault variant. It demonstrates how to set custom audience claims, Vault base URL, and retrieve authentication tokens from Vault.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/node/gitlab-ci-node@5.3.0
  # Vault variant
  - component: $CI_SERVER_FQDN/to-be-continuous/node/gitlab-ci-node-vault@5.3.0
    inputs:
      # audience claim for JWT
      vault-oidc-aud: "https://vault.acme.host"
      vault-base-url: "https://vault.acme.host/v1"

variables:
  NODE_CONFIG_SCOPED_REGISTRIES: "@public-repo:https://public.npm.registry/some/repo @my-priv-repo:https://private.npm.registry/another/repo"
  # retrieve private repo auth token from Vault
  NODE_REGISTRY_MY_PRIV_REPO_AUTH: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/node/priv-repo/creds?field=token"

```

--------------------------------

### Define sbt Repositories (.sbtrepositories)

Source: https://to-be-continuous.gitlab.io/doc/ref/sbt

Configure your project's repositories in `.sbtrepositories`. This example includes a local repository and mirrors for central and Confluent releases.

```ini
[repositories]
local
mirror_of_central: https://mavenrepo.acme.host/maven-proxy-asis-apache-releases
confluent-releases : https://mavenrepo.acme.host/maven-proxy-asis-confluent-releases

```

--------------------------------

### Example .netrc file for remote repository authentication

Source: https://to-be-continuous.gitlab.io/doc/ref/ansible

This example shows how to configure authentication for remote Ansible repositories using a .netrc file. It includes placeholders for GitLab CI job tokens and custom credentials.

```shell
machine gitlab.com login gitlab-ci-token password ${CI_JOB_TOKEN}
machine ansible.acme.example login ${ACME_ANSIBLE_USER} password ${ACME_ANSIBLE_PASSWORD}

```

--------------------------------

### Vault Variant Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/bruno

This example shows how to include both the main Bruno template and the Vault variant. Configure Vault connection details using `vault-oidc-aud` and `vault-base-url`. Secrets can be retrieved using the `@url@` syntax.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/bruno/gitlab-ci-bruno@1.12.0
  # Vault variant
  - component: $CI_SERVER_FQDN/to-be-continuous/bruno/gitlab-ci-bruno-vault@1.12.0
    inputs:
      # audience claim for JWT
      vault-oidc-aud: "https://vault.acme.host"
      vault-base-url: "https://vault.acme.host/v1"

variables:
  # Secrets managed by Vault
  MY_APP_TESTING_USER: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/testing/snapshot/credentials?field=user"
  MY_APP_TESTING_PASSWORD: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/testing/snapshot/credentials?field=password"

```

--------------------------------

### OpenShift DeploymentConfig Example

Source: https://to-be-continuous.gitlab.io/doc/ref/openshift

Defines the deployment configuration for an application in OpenShift, including replicas, strategy, and container specifications.

```yaml
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  annotations:
    description: The deployment configuration of application.
  labels:
    app: ${environment_name}
  name: ${environment_name}
spec:
  replicas: 1
  revisionHistoryLimit: 2
  selector:
    app: ${environment_name}
  strategy:
    type: Rolling
    rollingParams:
      timeoutSeconds: 3600
  template:
    metadata:
      labels:
        app: ${environment_name}
    spec:
      containers:
      - image: ${docker_image}
        imagePullPolicy: Always
        name: spring-boot
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        securityContext:
          privileged: false
  triggers:
  - type: ConfigChange
```

--------------------------------

### Vault Variant Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/kubernetes

Example of including the Vault variant and configuring Vault provider details. It shows how to set the Vault image, OIDC audience, and base URL. Secrets are retrieved using a specific URL format.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/kubernetes/gitlab-ci-k8s@9.2.0
    inputs:
      # ⚠ oc-container image (includes required curl)
      kubectl-image: docker.io/docker.io/appuio/oc:v4.14
  # Vault variant
  - component: $CI_SERVER_FQDN/to-be-continuous/kubernetes/gitlab-ci-k8s-vault@9.2.0
    inputs:
      # audience claim for JWT
      vault-oidc-aud: "https://vault.acme.host"
      vault-base-url: "https://vault.acme.host/v1"

variables:
    # Secrets managed by Vault
    K8S_DEFAULT_KUBE_CONFIG: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/my-app/kubernetes/noprod?field=kube_config"
    K8S_PROD_KUBE_CONFIG: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/my-app/kubernetes/prod?field=kube_config"
```

--------------------------------

### Helm Publish Script Example

Source: https://to-be-continuous.gitlab.io/doc/ref/helm

A custom shell script for implementing Helm publish methods. It can utilize package output variables and specific Helm publish variables.

```shell
helm-publish.sh
```

--------------------------------

### Example Cleanup Command

Source: https://to-be-continuous.gitlab.io/doc/ref/kubernetes

A common method for environment cleanup by deleting resources labeled with the environment name.

```bash
kubectl delete all,pvc,secret,ingress -l "app=${environment_name}"
```

--------------------------------

### DefectDojo and Vault Variant Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/defectdojo

This example demonstrates how to include both the main DefectDojo template and the Vault variant in your GitLab CI configuration. It shows how to provide the necessary inputs for both, including Vault server details and API keys managed by Vault.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/defectdojo/gitlab-ci-defectdojo@3.1.0
    inputs:
      server-url: "https://defectdojo.acme.host" # ⚠ this is only an example
      # Secrets managed by Vault
      api-key: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/defectdojo/credentials?field=token"
  # Vault variant
  - component: $CI_SERVER_FQDN/to-be-continuous/defectdojo/gitlab-ci-defectdojo-vault@3.1.0
    inputs:
      # audience claim for JWT
      vault-oidc-aud: "https://vault.acme.host"
      vault-base-url: "https://vault.acme.host/v1"
```

--------------------------------

### Helmfile Manifest Example

Source: https://to-be-continuous.gitlab.io/doc/ref/helmfile

This helmfile.yaml manifest illustrates the use of environment variables to configure releases, including image details and ingress hostnames, dynamically based on the deployment environment.

```yaml
environments:
  default:
  integration:
  review:
  production:
---
repositories:
  - name: mycharts
    url: https://repo.example.io/mycharts/stable
releases:
- name: {{ env "environment_name" | Default "myapp" }}
  chart: mycharts/webapp
  version: "1.2.0" 
  namespace: {{ .Namespace }}  
  values:
  - image:
      registry: {{ regexReplaceAll "^([^/]+)\/([^:^@]+)(@|:|)(.*)$" (env "docker_image") "${1}" }}
      repository: {{ regexReplaceAll "^([^/]+)\/([^:^@]+)(@|:|)(.*)$" (env "docker_image") "${2}" }}
      {{- if eq .Environment.Name "production" }}
      tag: {{ env "docker_tag" }}
      {{- else }}
      digest: {{ env "docker_digest" }}
      {{- end }}
    ingress:
      enabled: true
      hostname: {{ env "environment_hostname" }}

```

--------------------------------

### Configure Proxy and Daemon Properties

Source: https://to-be-continuous.gitlab.io/doc/ref/gradle

Example of setting proxy and daemon properties in gradle.properties based on CI/CD variables. These properties are added to the GRADLE_USER_HOME/gradle.properties file.

```yaml
variables:
    http_proxy: "http://the-proxy:8080"
    https_proxy: "http://the-proxy:8080"
    no_proxy: "localhost,my.neighbour.service"

```

```properties
org.gradle.daemon=false
systemProp.http.proxyHost=the-proxy
systemProp.http.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|my.neighbour.service
systemProp.https.proxyHost=the-proxy
systemProp.https.proxyPort=8080
systemProp.https.nonProxyHosts=localhost|my.neighbour.service

```

--------------------------------

### Star All TBC Templates

Source: https://to-be-continuous.gitlab.io/doc/community

Use this script to star all template projects hosted by 'to-be-continuous' on GitLab. It requires `curl` and `jq` to be installed and a `GITLAB_TOKEN` environment variable to be set.

```bash
curl -sSf "https://gitlab.com/api/v4/groups/to-be-continuous/projects?per_page=100" | jq -r '.[].id' | while read pid; do curl -X POST -H "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.com/api/v4/projects/$pid/star"; done

```

--------------------------------

### Configure Trivy Server

Source: https://to-be-continuous.gitlab.io/doc/ref/cnb

Set the TRIVY_SERVER environment variable to enable Trivy in client/server mode. This example points to a specific Trivy server address.

```yaml
variables:
  TRIVY_SERVER: "https://trivy.acme.host"

```

--------------------------------

### Vault Variant Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/dependency-track

Includes the main Dependency-Track template and the Vault variant template. Configures Vault connection details and a secret variable retrieved from Vault.

```yaml
include:
  # main template
  - project: 'to-be-continuous/dependency-track'
    ref: '2.1.0'
    file: '/templates/gitlab-ci-dependency-track.yml'
  # Vault variant
  - project: 'to-be-continuous/dependency-track'
    ref: '2.1.0'
    file: '/templates/gitlab-ci-dependency-track-vault.yml'

variables:
    # audience claim for JWT
    VAULT_OIDC_AUD: "https://vault.acme.host"
    # Secret managed by Vault
    DEPTRACK_API_KEY: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/runner/prod/deptrack?field=api-key"
    VAULT_BASE_URL: "https://vault.acme.host/v1"

```

--------------------------------

### dbt BigQuery profiles.yml Configuration

Source: https://to-be-continuous.gitlab.io/doc/ref/dbt

Example dbt profiles.yml configuration for BigQuery using the OAuth method. This setup is used in conjunction with the Google Cloud variant for authentication.

```yaml
my-bigquery-db:
  target: dev
  outputs:
    dev:
      type: bigquery
      method: oauth
      project: [GCP project id]
      dataset: [the name of your dbt dataset]
      threads: [1 or more]
      <optional_config>: <value>

```

--------------------------------

### Configure Lighthouse CI Run Options

Source: https://to-be-continuous.gitlab.io/doc/ref/lighthouse

This example demonstrates how to configure multiple URLs for Lighthouse analysis using the `$LHCI_RUN_OPTS` variable with late variable expansion. Ensure the `$environment_url` variable is propagated from an upstream job.

```yaml
include:
  - component: $CI_SERVER_FQDN/to-be-continuous/lighthouse/gitlab-ci-lighthouse@1.8.0
    inputs:
      run-opts: >- 
    --upload.target=filesystem 
    --collect.settings.chromeFlags="--no-sandbox"
    --collect.url="%{environment_url}"
    --collect.url="%{environment_url}/admin" 
    --collect.url="%{environment_url}/profile"

```

--------------------------------

### Install Jest and Testing Dependencies

Source: https://to-be-continuous.gitlab.io/doc/ref/angular

Install Jest and related testing packages as development dependencies for your Angular project.

```bash
npm install jest jest-preset-angular jest-junit @types/jest @angular-builders/jest --save-dev

```

--------------------------------

### Configure .bumpversion.toml for Setuptools

Source: https://to-be-continuous.gitlab.io/doc/ref/python

Use this configuration file to manage versioning for Setuptools projects with the bump-my-version tool.

```toml
[tool.bumpversion]
current_version = "0.0.0"

```

--------------------------------

### Install Istanbul for Mocha Code Coverage

Source: https://to-be-continuous.gitlab.io/doc/ref/node

Install the Istanbul package (`nyc`) as a dev dependency to enable code coverage reporting with Mocha.

```bash
npm install --save-dev nyc

```

--------------------------------

### Create User Provided Service Instance Command

Source: https://to-be-continuous.gitlab.io/doc/ref/cloud-foundry

The equivalent `cf` command to create a user-provided service instance with specified credentials.

```bash
cf cups my-ups -p '{"user":"service-user","password":"service-password","url":"https://my-service-endpoint.domain.com"}'
```

--------------------------------

### Vault Variant Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/ref/helm

Example of including the Vault variant in GitLab CI/CD configuration. It shows how to set Vault server details and retrieve secrets.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/helm/gitlab-ci-helm@9.5.0
  # Vault variant
  - component: $CI_SERVER_FQDN/to-be-continuous/helm/gitlab-ci-helm-vault@9.5.0
    inputs:
      # audience claim for JWT
      vault-oidc-aud: "https://vault.acme.host"
      vault-base-url: "https://vault.acme.host/v1"

variables:
  # Secrets managed by Vault
  HELM_DEFAULT_KUBE_CONFIG: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/my-app/helm/noprod?field=kube_config"
  HELM_PROD_KUBE_CONFIG: "@url@http://vault-secrets-provider/api/secrets/b7ecb6ebabc231/my-app/helm/prod?field=kube_config"
```

--------------------------------

### Enable Ready-to-Run Compilation

Source: https://to-be-continuous.gitlab.io/doc/ref/dotnet

Enable Ready-to-Run (R2R) compilation by setting `<PublishReadyToRun>true</PublishReadyToRun>`. This requires specifying runtime identifiers.

```xml
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <PublishReadyToRun>true</PublishReadyToRun>
    <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>
```

--------------------------------

### Configure Multiple Images Build with Parallel Matrix Jobs

Source: https://to-be-continuous.gitlab.io/doc/ref/cnb

Use the parallel matrix jobs pattern at the .cnb-base job level to enable building multiple images in parallel. This example configures the build for two applications, app1 and app2, specifying their artifact namespaces, source directories, and image names.

```yaml
.cnb-base:
  parallel:
    matrix:
      - CNB_ARTIFACTS_NAMESPACE: "app1"
        CNB_APP_DIR: "src/app1"
        CNB_SNAPSHOT_IMAGE: "$CI_REGISTRY_IMAGE/app1/snapshot:$CI_COMMIT_REF_SLUG"
        CNB_RELEASE_IMAGE: "$CI_REGISTRY_IMAGE/app1:$CI_COMMIT_REF_NAME"
      - CNB_ARTIFACTS_NAMESPACE: "app2"
        CNB_APP_DIR: "src/app2"
        CNB_SNAPSHOT_IMAGE: "$CI_REGISTRY_IMAGE/app2/snapshot:$CI_COMMIT_REF_SLUG"
        CNB_RELEASE_IMAGE: "$CI_REGISTRY_IMAGE/app2:$CI_COMMIT_REF_NAME"

```

--------------------------------

### Deploying Multiple Static Websites with Parallel Matrix

Source: https://to-be-continuous.gitlab.io/doc/ref/s3

Configure GitLab CI/CD to deploy multiple static websites (e.g., 'doc' and 'dev-guide') from a monorepo to S3 using parallel matrix jobs. This leverages `S3_ENVIRONMENT_NAMESPACE` to create distinct deployment paths for each component.

```yaml
.s3-base:
  parallel:
    matrix:
      - S3_ENVIRONMENT_NAMESPACE: /doc
        S3_SCRIPTS_DIR: doc
        S3_PREFIX: doc
        S3_DEPLOY_FILES: doc/public/
      - S3_ENVIRONMENT_NAMESPACE: /dev-guide
        S3_SCRIPTS_DIR: dev-guide
        S3_PREFIX: dev-guide
        S3_DEPLOY_FILES: dev-guide/public/

# ⚠ on_stop must be unset when defining parallel:matrix environments
# see: https://gitlab.com/gitlab-org/gitlab/-/issues/332247
s3-review:
  environment:
    on_stop: null

```

--------------------------------

### Publish to Azure Container Registry Example

Source: https://to-be-continuous.gitlab.io/doc/ref/docker

This example demonstrates how to include the necessary components and configure inputs for publishing container images to Azure Container Registry. Ensure you have a Container Registry, a managed identity or application with the 'Container Registry Repository Writer' role, and federated identity credentials.

```yaml
include:
  - component: $CI_SERVER_FQDN/to-be-continuous/docker/gitlab-ci-docker@8.3.0
    inputs:
      build-tool: "kaniko" # Only Kaniko has been proved to work for this use case YET
      # untested & unverified container image
      snapshot-image: "{YOUR_REPOSITORY}.azurecr.io/{YOUR_IMAGE_NAME}/snapshot:$CI_COMMIT_REF_SLUG"
      # validated container image (published)
      release-image: "{YOUR_REPOSITORY}.azurecr.io/{YOUR_IMAGE_NAME}:$CI_COMMIT_REF_NAME"
  - component: $CI_SERVER_FQDN/to-be-continuous/docker/gitlab-ci-docker-acr@8.3.0
    inputs:
      # default Azure tenant id
      azure-tenant-id: "12345678-acbd-abcd-acbd-1234567890ab"
      # default Azure client id
      azure-client-id: "abcdef01-2345-6789-0123-abcdef012345"

```

--------------------------------

### Include Helm Chart and GCP Auth Provider

Source: https://to-be-continuous.gitlab.io/doc/ref/helm

This example demonstrates how to include the main Helm chart template and the GCP auth variant. It shows how to specify the publish URL for GCP Artifact Registry and configure the default Workload Identity Provider and Service Account for GCP authentication.

```yaml
include:
  # main template
  - component: $CI_SERVER_FQDN/to-be-continuous/helm/gitlab-ci-helm@9.5.0
    inputs:
      # GCP Artifact Registry url
      publish-url: "oci://{GCP_REGION}-docker.pkg.dev/${GCP_PROJECT_ID}/charts"
  # GCP auth variant
  - component: $CI_SERVER_FQDN/to-be-continuous/helm/gitlab-ci-helm-gcp@9.5.0
    inputs:
      # default WIF provider
      gcp-oidc-provider: "projects/{GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/{YOUR_WIF_POOL_NAME}/providers/gitlab-diod"
      # default GCP Service Account
      gcp-oidc-account: "{YOUR_REGISTRY_SA}@{GCP_PROJECT_ID}.iam.gserviceaccount.com"

```

--------------------------------

### Bash Length Expansion in Ash

Source: https://to-be-continuous.gitlab.io/doc/dev/shell

Get the length of a string parameter. Supported in Ash.

```bash
${#parameter}
```

--------------------------------

### Configure sbt Repositories (.sbtopts)

Source: https://to-be-continuous.gitlab.io/doc/ref/sbt

Add this content to your `.sbtopts` file to enable overriding build repositories and specify a custom repository configuration file.

```properties
-Dsbt.override.build.repos=true
-Dsbt.repository.config=.sbtrepositories

```

--------------------------------

### Base64 Encoded Secret Example

Source: https://to-be-continuous.gitlab.io/doc/ref/dbt

Prefix Base64 encoded secrets with '@b64@' for automatic decoding and masking.

```yaml
MY_SECRET: "@b64@your_base64_encoded_secret"
```

--------------------------------

### OpenShift Route Example

Source: https://to-be-continuous.gitlab.io/doc/ref/openshift

Exposes an OpenShift service at a specific hostname, defining how external traffic reaches the application.

```yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    description: The route exposes the service at a hostname.
  labels:
    app: ${environment_name}
  name: ${environment_name}
spec:
  host: ${hostname}
  port:
    targetPort: 8080
  to:
    kind: Service
    name: ${environment_name}
```

--------------------------------

### Include CI/CD Templates from Projects

Source: https://to-be-continuous.gitlab.io/doc/usage

Use `include:project` for the former GitLab syntax, which is similar to components but configures templates using `variables`. Specify the project, ref (version/branch), and file path.

```yaml
include:
  # Maven template with exact version '3.9.0'
  - project: "to-be-continuous/maven"
    ref: "3.9.0"
    file: "templates/gitlab-ci-maven.yml"
  # AWS template with minor version alias '5.2' (uses the latest available patch version)
  - project: "to-be-continuous/aws"
    ref: "5.2"
    file: "templates/gitlab-ci-aws.yml"

```

--------------------------------

### Make Readiness Check Script Executable

Source: https://to-be-continuous.gitlab.io/doc/ref/kubernetes

Set the execute flag on the readiness check script using git.

```bash
git update-index --chmod=+x k8s-readiness-check.sh
```

--------------------------------

### Configure Ajax Front-end Deployment

Source: https://to-be-continuous.gitlab.io/doc/ref/cloud-foundry

Example GitLab CI/CD configuration for deploying an Ajax front-end application. This includes setting up Cloud Foundry variables for API endpoint, organization, spaces, and domains for review and production environments.

```yaml
include:
  - project: "to-be-continuous/cloud-foundry"
    ref: "7.2.0"
    file: "/templates/gitlab-ci-cf.yml"

# Global variables
variables:
  # specific project variables
  # TODO
  # Cloud Foundry CI template variables
  CF_URL: "https://api.cloud-foundry.acme.host"
  CF_ORG: "MyProject" # one single Organization for all spaces
  # CF_USER and CF_PASSWORD are defined as protected project CI/CD variables
  CF_REVIEW_SPACE: "Integration"
  CF_REVIEW_ENVIRONMENT_DOMAIN: "apps.cloud-foundry.acme.host" # intranet route
  # CF_STAGING_SPACE not defined: no staging environment; continuous deployment
  CF_PROD_SPACE: "Production"
  # CF_DEFAULT_DOMAIN not defined: use CF default domain by default
  CF_PROD_DOMAIN: "acme.com" # on prod: use my own internet domain
  CF_PROD_ENVIRONMENT_URL: "https://frontend.myproject.acme.com" # internet route
  CF_PROD_DEPLOY_STRATEGY: "auto"

build:
  stage: build
  script:
    - echo "build the front-end (TODO)"
  only:
    refs:
      - branches
```

--------------------------------

### KICKER_RESOURCE_GROUPS Configuration Example

Source: https://to-be-continuous.gitlab.io/doc/self-managed/advanced

JSON configuration for KICKER_RESOURCE_GROUPS, specifying GitLab groups to crawl for Kicker resources, including visibility and exclusions.

```json
[
  {
    "path": "acme/cicd/all", 
    "visibility": "public"
  },
  {
    "path": "acme/cicd/ai-ml", 
    "visibility": "internal", 
    "exclude": ["project-2", "project-13"],
    "extension": 
      {
        "id": "ai-ml", 
        "name": "AI/ML", 
        "description": "ACME templates for AI/ML projects"
      }
  },
  {
    "path": "to-be-continuous", 
    "visibility": "public"
  }
]
```

--------------------------------

### Configure GolangCI-Lint Job

Source: https://to-be-continuous.gitlab.io/doc/ref/golang

Enable and configure the GolangCI-Lint job for static analysis. Customize the Docker image and command-line arguments as needed.

```yaml
golangci-lint:
  image: "${GO_CI_LINT_IMAGE}"
  args: ${GO_CI_LINT_ARGS}
  disabled: ${GO_CI_LINT_DISABLED}

```

--------------------------------

### Prefix Terraform Resource Names

Source: https://to-be-continuous.gitlab.io/doc/ref/terraform

Example of how to prefix Terraform resource names with the `environment_slug` variable to ensure uniqueness across environments.

```hcl
resource "aws_instance" "web_server" {
  name = "myproj_${var.environment_slug}_web_server"
  ...
}

```

--------------------------------

### Include GitOps CI/CD Template (Legacy)

Source: https://to-be-continuous.gitlab.io/doc/ref/gitops

Include the GitOps CI/CD template using the legacy `include:project` syntax in your `.gitlab-ci.yml`. Define `GITOPS_TRIGGER_XXX` variables in your project's CI/CD settings.

```yaml
include:
  # 1: include the template
  - project: "to-be-continuous/gitops"
    ref: "2.2.0"
    file: "/templates/gitlab-ci-gitops.yml"

# 2: GITOPS_TRIGGER_XXX variables are defined as project CI/CD variables

```

--------------------------------

### Install Jest and Jest-JUnit

Source: https://to-be-continuous.gitlab.io/doc/ref/puppeteer

Add Jest and jest-junit as development dependencies using npm. This is required for generating JUnit test reports.

```bash
npm install --save-dev jest jest-junit

```

--------------------------------

### Create Cloud Foundry Service Instance Command

Source: https://to-be-continuous.gitlab.io/doc/ref/cloud-foundry

The equivalent `cf` command to create the service instance described by the JSON configuration.

```bash
cf create-service logarythm_drain_prod httpdrain logarythm_drain_catalog -c '{"cloudid": "stg_ods_m_00.aed.lizard.o6o3knwikgjewx4il6rq","component":"int","env":"ep1"}'
```

--------------------------------

### OpenShift Cleanup Command Example

Source: https://to-be-continuous.gitlab.io/doc/ref/openshift

This command can be used in a script-based cleanup to delete all OpenShift objects associated with an environment by targeting the 'app' label.

```shell
oc delete all,pvc,is,secret -l "app=${environment_name}"
```

--------------------------------

### Integrate JUnit Test Reports

Source: https://to-be-continuous.gitlab.io/doc/ref/make

Declare JUnit test reports in your .gitlab-ci.yaml for the 'make-build' job. This example specifies 'reports/xyz-test.xunit.xml' as the location for the reports.

```yaml
make-build:
  artifacts:
    reports:
      junit: "reports/xyz-test.xunit.xml"

```

--------------------------------

### Escape Special Characters in Secrets

Source: https://to-be-continuous.gitlab.io/doc/ref/dependency-track

Ensure special characters within secret variables are properly escaped. For example, a dollar sign `$` should be represented as `$$`.

```text
MY_ESCAPED_VAR: "$$100"
```

--------------------------------

### Configure Trivy Server Mode

Source: https://to-be-continuous.gitlab.io/doc/ref/maven

Enable client/server mode for Trivy by specifying the server address.

```bash
TRIVY_SERVER: "<server_address>"
```

--------------------------------

### Dockerfile for Pre-commit Image

Source: https://to-be-continuous.gitlab.io/doc/ref/pre-commit

Use this Dockerfile to build a custom image containing pre-commit and essential hooks. Ensure you have Docker installed and configured.

```docker
FROM docker.io/library/python:3-alpine

RUN mkdir /build

RUN apk add --no-cache git && \
    rm -rf /var/cache/apk/*

WORKDIR /build

RUN pip install --no-cache-dir pre-commit==3.5.0

RUN cat <<EOF > hook-install-config.yaml
repos:
    - repo: https://github.com/pre-commit/pre-commit-hooks
      rev: v4.5.0
      hooks:
        - id: no-commit-to-branch
        - id: trailing-whitespace
        - id: check-merge-conflict
        - id: check-yaml
        - id: end-of-file-fixer
        - id: fix-byte-order-marker
        - id: mixed-line-ending
EOF

COPY hook-install-config.yaml ./.pre-commit-config.yaml

RUN git init && \
    pre-commit install-hooks && \
    rm ./.pre-commit-config.yaml && \
    rm -rf .git

CMD ["--help"]

ENTRYPOINT ["pre-commit"]

```

--------------------------------

### Environment URL Configuration with Late Variable Expansion

Source: https://to-be-continuous.gitlab.io/doc/ref/kubernetes

Shows how to configure environment URLs using static and dynamic methods, including late variable expansion with the `%{VARIABLE_NAME}` syntax. This allows for dynamic values like environment names to be embedded in URLs.

```yaml
variables:
  K8S_BASE_APP_NAME: "wonderapp"
  # global url for all environments
  K8S_ENVIRONMENT_URL: "https://%{environment_name}.nonprod.acme.domain"
  # override for prod (late expansion of $K8S_BASE_APP_NAME not needed here)
  K8S_PROD_ENVIRONMENT_URL: "https://$K8S_BASE_APP_NAME.acme.domain"
  # override for review (using separate resource paths)
  K8S_REVIEW_ENVIRONMENT_URL: "https://wonderapp-review.nonprod.acme.domain/%{environment_name}"

```

--------------------------------

### Scope Variable by Environment

Source: https://to-be-continuous.gitlab.io/doc/usage

Example of overriding variables based on the CI_ENVIRONMENT_NAME. This is useful for setting environment-specific configurations like API URLs or database passwords.

```yaml
variables:
  # default configuration
  K8S_URL: "https://my-nonprod-k8s.domain"
  MY_DATABASE_PASSWORD: "admin"

  # overridden for prodution environment
  scoped__K8S_URL__if__CI_ENVIRONMENT_NAME__equals__production: "https://my-prod-k8s.domain"
  # MY_DATABASE_PASSWORD is overridden for prod in my project CI/CD variables using
  # scoped__MY_DATABASE_PASSWORD__if__CI_ENVIRONMENT_NAME__equals__production
```
Tokens:
Raw