Components

Lista komponentów

• 1: prepare
• 1.1: 🛠 Job template: Input Parameters
• 1.2: 🛠 Job template: Analyze Conventional Commits
• 2: validate
• 2.1: 🛠 Job template: 🔬 Validate files (conftest)
• 2.2: 🛠 Job template: 🕵 yamllint
• 3: release
• 3.1: 🛠 Job template: Publish Version
• 4: Application Security Testing
• 4.1: 🛠 Job template: 💪 SonarQube Scanner (SAST)
• 4.2: 🛠 Job template: 🔬 Trivy image scan (DAST)
• 5: containers
• 5.1: 🛠 Job template: 🚀 Image bulder
• 6: infrastructure
• 6.1: 🛠 Job template: OpenTofu
• 6.2: 🛠 Job template: Terraform

Poniżej znajduje się lista stworzonych komponentów

---

component	version
ast
build
deploy
prepare
release
sast
unit-test
validate

1 - prepare

1.1 - 🛠 Job template: Input Parameters

Job, który wyświetla informacje o zmiennych procesowych CI

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe obsługiwane przez skrypt

Komponent wypisuje wartości m.in. następujących zmiennych:

• GITLAB_CI_VERSION
• COMPONENT_VERSION_*
• COMPONENT_VERSION_DEPLOY
• CONTAINER_IMAGE_*
• CONTAINER_IMAGE_PYTHON
• VAULT_ADDR
• SONAR_HOST_URL

📤 Output

Skrypt wypisuje dane w formie tabeli ASCII w logach pipeline’u, np.:

===> 💾 Print set inputs Variables
┌────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Variable                       │ Value                                                                                               │
├────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ CONTAINER_IMAGE_TERRAFORM      │ registry.gitlab.com/pl.rachuna-net/containers/terraform:1.0.0                                       │
│ COMPONENT_VERSION_DEPLOY       │ v1.2.3                                                                                              │
...
└────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────┘

🧪 Przykład użycia

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/prepare/input_parameters@$COMPONENT_VERSION_PREPARE
    inputs:
      docker_image: $CONTAINER_IMAGE_PYTHON

🔍 input parameters:
  stage: prepare
  rules:
    - when: on_success

1.2 - 🛠 Job template: Analyze Conventional Commits

🔍 Analyze Conventional Commits

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/prepare/conventional_commits@$COMPONENT_VERSION_PREPARE
    inputs:
      docker_image: $CONTAINER_IMAGE_PYTHON

🔍 Analyze Conventional Commits:
  stage: prepare
  rules:
    - when: on_success

2 - validate

2.1 - 🛠 Job template: 🔬 Validate files (conftest)

Wymagania wstępne

• conftest

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobie

• CONTAINER_IMAGE_CONFTEST – obraz Dockera Conftest (na podstawie inputs.docker_image)
• LOGO_URL – ścieżka do logo (na podstawie inputs.logo_url)
• REPOSITORY_POLICIES – repozytorium z politykami
• REPOSITORY_POLICIES_BRANCH – branch repozytorium z politykami
• REPOSITORY_POLICIES_PATH – katalog polityk w repozytorium
• SOURCE_FILES – pliki do testowania
• NAMESPACE_POLICY – przestrzeń nazw polityk Conftest

📤 Output

Job wykonuje następujące kroki:

1. Pobranie logo (jeżeli LOGO_URL jest ustawiony).
2. Wyświetlenie informacji o przekazanych parametrach (_function_print_row).
3. Klonowanie repozytorium z politykami (repository_policies) w odpowiednim branchu.
4. Uruchomienie Conftest z wykorzystaniem wskazanych plików (source_files) i polityk (repository_policies_path) w przestrzeni nazw namespace_policy.

Przykład logu:

===> 🔬 Conftest Validate - Parameters
┌───────────────────────────────────┬─────────────────────────────────────────────────────┐
│ Variable                          │ Value                                               │
├───────────────────────────────────┼─────────────────────────────────────────────────────┤
│ REPOSITORY_POLICIES               │ git@gitlab.com:pl.rachuna-net/discipline.git        │
│ REPOSITORY_POLICIES_PATH          │ policies/conftest                                   │
│ SOURCE_FILES                      │ *.yml                                               │
└───────────────────────────────────┴─────────────────────────────────────────────────────┘

🧪 Dostępne joby

🔬 Validate files (conftest)

Waliduje wskazane pliki repozytorium względem polityk Conftest:

🔬 Validate files (conftest):
  stage: validate
  image: $CONTAINER_IMAGE_CONFTEST
  before_script:
    - git config --global --add safe.directory ${CI_PROJECT_DIR}
    - [ ! -z "${LOGO_URL}" ] && curl -s "${LOGO_URL}"
    - !reference [.validate:_function_print_row]
    - !reference [.validate:conftest_input_variables]
    - !reference [.validate:conftest_prepare]
  script:
    - conftest test $SOURCE_FILES --policy $REPOSITORY_POLICIES_PATH --namespace $NAMESPACE_POLICY

🧪 Przykład użycia w pipeline

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/validate/conftest@$COMPONENT_VERSION_VALIDATE
    inputs:
      repository_policies: git@gitlab.com:pl.rachuna-net/discipline.git
      repository_policies_path: policies/k8s
      source_files: "config.yml"
      namespace_policy: image_builder

⚡ Dzięki temu szablonowi szybko weryfikujesz zgodność konfiguracji z politykami OPA/Conftest bez ręcznej konfiguracji za każdym razem w pipeline’ach.

2.2 - 🛠 Job template: 🕵 yamllint

Job, który wykonuje walidację składni plików YAML w repozytorium przy użyciu narzędzia yamllint.

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe obsługiwane przez skrypt

Job ustawia i wykorzystuje poniższe zmienne środowiskowe:

• CONTAINER_IMAGE_PYTHON – wybrany obraz Dockera.
• LOGO_URL – adres logotypu, który jest opcjonalnie pobierany w trakcie uruchamiania joba.
• VALIDATE_REPO_NAMESPACE – namespace repozytorium komponentu validate.
• VALIDATE_REPO_BRANCH – gałąź repozytorium komponentu validate.
• YAMLLINT_PATH – ścieżka do pliku konfiguracyjnego yamllint.

📤 Output

Job wykonuje linting plików YAML i wypisuje wyniki w logach pipeline’u w formie standardowej dla narzędzia yamllint, np.:

===> 🔍 YAML lint results
source/ci-template.yml
  10:3      warning  missing document start "---"  (document-start)
  22:1      error    too many blank lines (1 > 0)  (empty-lines)

W przypadku błędów job kończy się statusem failed.

3 - release

3.1 - 🛠 Job template: Publish Version

Wersjonowania kodu

Job, który odpowiada za wersjonowanie i publikację zmian w repozytorium za pomocą narzędzia semantic-release. Szablon składa się z dwóch kroków:

1. 🕵 Set Version – ustawia wersję w trybie dry-run (przygotowanie).
2. 📍 Publish Version – publikuje nową wersję (release).

[!NOTE]

Wymagania:

• Obraz kontenera dostępny jest tutaj.
• Stosowanie standardu opisywania commitów Conventional Commits

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe obsługiwane przez skrypt

Job ustawia i wykorzystuje poniższe zmienne środowiskowe:

• CONTAINER_IMAGE_SEMANTIC_RELEASE – obraz Dockera z semantic-release.
• LOGO_URL – adres logotypu.
• DEBUG – flaga debugowania (dziedziczona z inputs.debug).
• VERSIONING_DEBUG – włącza dodatkowy debug semantic-release.
• VERSIONING_DRY_RUN – uruchamia semantic-release w trybie dry-run.
• COMPONENT_REPO_NAMESPACE – namespace repozytorium komponentu.
• COMPONENT_REPO_BRANCH – gałąź repozytorium komponentu.
• RELEASERC_FILE – ścieżka do pliku .releaserc.js.

📤 Output

Job generuje:

1. Plik CHANGELOG.md – zawierający opis zmian.

2. Plik versioning.env (zapisany jako artifact dotenv) z informacjami o wersji, np.:

   VERSION=1.2.3
   VERSION_MAJOR=1
   VERSION_MINOR=2
   VERSION_PATCH=3
   

3. Logi semantic-release z informacją o wygenerowanej wersji i ewentualnie o publikacji.

📝 Przykładowe użycie w pipeline

include:
  - component: '$CI_SERVER_FQDN/pl.rachuna-net/cicd/components/release@$COMPONENT_VERSION_RELEASE'
    inputs:
      docker_image: "registry.gitlab.com/pl.rachuna-net/containers/semantic-release:2.0.0"
      debug: "true"
      dry_run: "false"

🔎 Kroki joba

🕵 Set Version

• Stage: prepare
• Uruchamia semantic-release w trybie dry-run (VERSIONING_DRY_RUN: "true") w celu przygotowania wersji i changeloga.

📍 Publish Version

• Stage: release
• Uruchamia semantic-release w trybie pełnym (publikacja wersji i generacja changeloga).

Jak działa komponent?

Analiza brancha

W pierwszej kolejności sprawdzane jest - czy można zwersjonować aplikacje na odpowiednim branchu

"branches": [
    { 
      "name": "feature/*", 
      "channel": "feat-${name.replace(/^feature\\//, '').substring(0, 20)}", 
      "prerelease": "feat-${name.replace(/^feature\\//, '').substring(0, 20)}" 
    },
    { 
      "name": "epic/*", 
      "channel": "epic-${name.replace(/^epic\\//, '').replace(/[^A-Za-z0-9]/, '').substring(0, 20)}", 
      "prerelease": "epic-${name.replace(/^epic\\//, '').replace(/[^A-Za-z0-9]/, '').substring(0, 20)}" 
    },
    { "name": "alpha", "channel": "alpha", "prerelease": true },
    { "name": "release", "channel": "rc", "prerelease": true },
    { "name": "hotfix", "channel": "ht", "prerelease": true },
    { "name": "main" }
],

Sprawdzanie convensional commits

Komponent sprawdza, czy czyta wszystkie informacje o commitach zgodnie z standardem Conventional Commits

"plugins": [
[ "@semantic-release/commit-analyzer",
    {
        "preset": "conventionalcommits",
        "releaseRules": [
            { "breaking": true, "release": "major" },
            { "type": "feat", "release": "minor" },
            { "type": "fix", "release": "patch" },
            { "type": "style", "release": "patch" },
            { "type": "perf", "release": "patch" },
            { "type": "test", "release": "patch" },
            { "type": "docs", "release": "patch" },
            { "type": "sec", "release": "patch" }
        ]
    }
],

Generowanie releases notes

Następnie generuje release notes

[
    "@semantic-release/release-notes-generator",
    {
        "preset": "conventionalcommits",
        "presetConfig": {
            "types": [
              { "type": "feat", "section": "✨ Features ✨" },
              { "type": "fix", "section": "🐛 Bug Fixes 🐛" },
              { "type": "revert", "section": "⏮️️ Reverts ⏮️️" },
              { "type": "perf", "section": "🔧 Performance Improvements 🔧" },
              { "type": "docs", "section": "📝 Documentation 📝" },
              { "type": "build", "section": "📀 Build 📀" },
              { "type": "test", "section": "💚 Tests 💚" },
              { "type": "ci", "section": "🏁 CI/CD 🏁" }
            ]
        }
    }
],

Generowanie chandelog.md

Generowanie localnie pliku CHANGELOG.md

[
    "@semantic-release/changelog",
    {
      "changelogFile": "CHANGELOG.md"
    }
],

Integracja z gitlab

Integracja z gitab

[
    "@semantic-release/gitlab"
]

Ustawienie zmiennych środowiskowych

{
  name: "versioning-variables",
  generateNotes: (pluginConfig, context) => {
    const releaseNote = context.nextRelease.notes;
    const nextVersion = context.nextRelease.version;

    // Check if the version is a final version or a snapshot
    const finalVersionRegex = /(\d+\.\d+\.\d+)/;
    const matchFinalVersion = nextVersion.match(finalVersionRegex);
    let artifactType = "snapshot";
    if (matchFinalVersion) {
      artifactType = "release";
    }

    // Extract JIRA issues from commits
    const jiraRegexp = /\b[A-Z][A-Z0-9_]+-[1-9][0-9]*/g;
    const jiraSet = new Set();

    for (const commit of context.commits) {
      if (commit.message) {
        const matchJIRA = commit.message.match(jiraRegexp);
        if (matchJIRA) {
          matchJIRA.forEach(jira => jiraSet.add(match));
        }
      }
    }

    // Create a file with the environment variables
    const uniqJiraList = Array.from(jiraSet)
    const environmentList = [
      { key: "RELEASE_CANDIDATE_VERSION", value: nextVersion },
      { key: "ARTIFACTS_TYPE", value: artifactType },
      { key: "JIRA_ISSUES_IDS", value: uniqJiraList.join(", ") }
    ]
    const fileContent = environmentList.map(env => `${env.key}=${env.value}`).join("\n");
    fs.writeFileSync("versioning.env", fileContent);
  }
}

Linki

• SemVer
• semantic-release

4 - Application Security Testing

- Application Security Testing

4.1 - 🛠 Job template: 💪 SonarQube Scanner (SAST)

Wymagania wstępne

• SonarQube Scanner – dostępny w obrazie Dockera ustawianym przez inputs.docker_image.
• Skonfigurowane konto w SonarCloud lub własnej instancji SonarQube (parametry: sonar_host_url, sonar_token, sonar_project_key).

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobie

• CONTAINER_IMAGE_SONAR_SCANNER – obraz Dockera SonarQube Scanner (na podstawie inputs.docker_image)
• SONAR_USER_HOME – katalog roboczy SonarQube
• SONAR_HOST_URL – adres instancji SonarQube/SonarCloud
• SONAR_ORGANIZATION – nazwa organizacji
• SONAR_PROJECT_KEY – klucz projektu w SonarQube
• SONAR_PROJECT_NAME – nazwa projektu
• SONAR_PROJECT_DESCRIPTION – opis projektu
• SONAR_PROJECT_VERSION – wersja projektu
• SONAR_SOURCES – ścieżki źródeł do analizy
• SONAR_TOKEN – token uwierzytelniający do SonarQube

📤 Output

Job wykonuje następujące kroki:

2. Wyświetlenie zmiennych wejściowych i konfiguracji SonarQube.

3. Uruchomienie SonarQube Scanner z zadeklarowanymi parametrami:

   • analiza kodu z podanych źródeł (SONAR_SOURCES),
   • przesłanie wyników do wskazanej instancji (SONAR_HOST_URL).

Pipeline zakończy się niepowodzeniem, jeśli analiza SonarQube wykryje błędy jakościowe powodujące blokadę (quality gate failure).

🧪 Dostępny job

💪 sonarqube scanner (sast)

Analizuje kod źródłowy i przesyła wyniki do SonarQube/SonarCloud:

💪 sonarqube scanner:
  stage: sast
  image: $CONTAINER_IMAGE_SONAR_SCANNER
  before_script:
    - git config --global --add safe.directory ${CI_PROJECT_DIR}
    - [ ! -z "${LOGO_URL}" ] && curl -s "${LOGO_URL}"
    - !reference [.ast:_function_print_row]
    - !reference [.ast:sonarqube_input_variables]
    - !reference [.ast:sonarqube-init]
  script:
    - |
      sonar-scanner \
        -Dsonar.projectKey="${SONAR_PROJECT_KEY}" \
        -Dsonar.organization="${SONAR_ORGANIZATION}" \
        -Dsonar.projectName="${SONAR_PROJECT_NAME}" \
        -Dsonar.projectDescription="${CI_PROJECT_DESCRIPTION}" \
        -Dsonar.projectVersion="${SONAR_PROJECT_VERSION}" \
        -Dsonar.sources="${SONAR_SOURCES}" \
        -Dsonar.sourceEncoding=UTF-8 \
        -Dsonar.token="${SONAR_TOKEN}"
  rules:
    - when: on_success

🧪 Przykład użycia w pipeline

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/ast/sonarqube@$COMPONENT_VERSION_SONARQUBE

💪 sonarqube scanner:
  variables:
    SONAR_PROJECT_KEY: $CI_PROJECT_NAME
    SONAR_PROJECT_NAME: "Project $CI_PROJECT_NAME"
    SONAR_TOKEN: $SONAR_TOKEN
  rules:
    - when: on_success

4.2 - 🛠 Job template: 🔬 Trivy image scan (DAST)

Wymagania wstępne

• Trivy – wbudowany w używany obraz Dockera (ustawiany przez inputs.docker_image).
• Obraz kontenera, który ma zostać przeskanowany (ustawiany przez inputs.container_to_analyze).

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobie

• CONTAINER_IMAGE_TRIVY – obraz Dockera Trivy (na podstawie inputs.docker_image)
• CONTAINER_TO_ANALYZE – nazwa obrazu kontenera do przeskanowania (na podstawie inputs.container_to_analyze)
• TRIVY_NO_PROGRESS – wyłącza pasek postępu w logach (domyślnie true)
• TRIVY_CACHE_DIR – lokalny katalog cache Trivy (domyślnie .trivycache/)

📤 Output

Job wykonuje następujące kroki:

1. Uruchomienie skanowania obrazu kontenera (CONTAINER_TO_ANALYZE) z użyciem Trivy:

   • Najpierw wyszukiwanie luk o poziomie HIGH – raport ostrzegawczy (--exit-code 0).
   • Następnie wyszukiwanie luk o poziomie CRITICAL – pipeline zakończy się niepowodzeniem, jeśli takie wystąpią (--exit-code 1).

2. Wykorzystanie cache Trivy w katalogu .trivycache/ w celu przyspieszenia kolejnych skanów.

🧪 Dostępny job

🔬 trivy (dast)

Skanuje wskazany obraz kontenera i kończy pipeline, jeśli znajdzie luki o poziomie CRITICAL:

🔬 trivy (dast):
  image: $CONTAINER_IMAGE_TRIVY
  stage: integration-test
  services:
    - name: $CONTAINER_IMAGE_TRIVY
      alias: buildah-dind
  allow_failure: true
  before_script:
    - git config --global --add safe.directory ${CI_PROJECT_DIR}
    - [ ! -z "${LOGO_URL}" ] && curl -s "${LOGO_URL}"
    - !reference [.ast:trivy_input_variables]
  script:
    - trivy image --exit-code 0 --severity HIGH $CONTAINER_TO_ANALYZE
    - trivy image --exit-code 1 --severity CRITICAL $CONTAINER_TO_ANALYZE
  cache:
    paths:
      - .trivycache/

🧪 Przykład użycia w pipeline

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/ast/trivy@$COMPONENT_VERSION_TRIVY

🔬 trivy (dast):
  allow_failure: true
  variables:
    CONTAINER_TO_ANALYZE: $CI_REGISTRY_IMAGE:$RELEASE_CANDIDATE_VERSION
  rules:
    - when: on_success

5 - containers

5.1 - 🛠 Job template: 🚀 Image bulder

Wymagania wstępne

• Buildah – wbudowany w używany obraz Dockera (ustawiany przez inputs.docker_image).
• Dostęp do rejestru Docker/GitLab (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD).
• Plik konfiguracyjny obrazu kontenera (buildah_config_path).

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobie

• CONTAINER_IMAGE_BUILDAH – obraz Dockera Buildah (na podstawie inputs.docker_image)
• LOGO_URL – ścieżka do logo (na podstawie inputs.logo_url)
• CONTAINER_VERSION – wersja obrazu (na podstawie inputs.container_version)
• FULL_IMAGE_NAME – pełna nazwa obrazu: $CI_REGISTRY_IMAGE:$CONTAINER_VERSION
• BUILDAH_CONFIG_FILE_PATH – ścieżka do pliku konfiguracji Buildah (na podstawie inputs.buildah_config_path)
• DOCKER_TEST_SCRIPT_PATH – skrypt testowy do uruchomienia w kontenerze
• Dodatkowe zmienne konfiguracyjne Buildah: STORAGE_DRIVER, BUILDAH_FORMAT, BUILDAH_ISOLATION, BUILDAH_STORAGE_ROOT, BUILDAH_STORAGE_RUNROOT

📤 Output

Szablon wykonuje następujące kroki:

1. Budowanie obrazu kontenera na podstawie buildah_config_path:

   • Pobranie obrazu bazowego (base_image)
   • Instalacja pakietów i certyfikatów
   • Dodanie repozytoriów (custom_repos)
   • Kopiowanie plików i ustawienie zmiennych środowiskowych
   • Tworzenie użytkownika nie-root (opcjonalnie)
   • Ustawienie ENTRYPOINT oraz CMD

2. Zapis obrazu do tarballa (container-image.tar).

3. Publikacja obrazu w rejestrze Docker/GitLab (job 🌐 publish container image).

4. Testowanie obrazu z wykorzystaniem skryptu testowego (job 🧪 test docker image).

🧪 Dostępne joby

🚀 build container image

Buduje obraz kontenera na podstawie pliku konfiguracyjnego config.yml

Przykładowy plik config yml:

---
base_image: ubuntu:noble

labels:
  maintainer: "Maciej Rachuna <rachuna.maciej@gmail.com>"
  version: "1.0.0"
  image_source: "https://gitlab.com/pl.rachuna-net/containers/terraform"

env:
  DEBIAN_FRONTEND: noninteractive
  TF_IN_AUTOMATION: "true"
  LANG: C.UTF-8

before_build_commands:
  ## terraform docs
  - curl -sLo ./terraform-docs.tar.gz https://github.com/terraform-docs/terraform-docs/releases/download/v0.20.0/terraform-docs-v0.20.0-linux-amd64.tar.gz
  - tar -xzf terraform-docs.tar.gz
  - chmod +x terraform-docs
  ## terraform lint
  - curl -sLo ./tflint_linux_amd64.zip https://github.com/terraform-linters/tflint/releases/download/v0.58.1/tflint_linux_amd64.zip
  - unzip tflint_linux_amd64.zip
  - chmod +x tflint

packages:
  - bash
  - curl
  - git
  - gnupg2
  - jq
  - libssl3
  - lsb-release
  - openssh-client
  - ca-certificates
  - gnupg
  - terraform

custom_repos:
  - name: hashicorp
    key_url: https://apt.releases.hashicorp.com/gpg
    key_path: /usr/share/keyrings/hashicorp-archive-keyring.gpg
    repo_entry: >-
      deb [arch=amd64 signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg trusted=yes] https://apt.releases.hashicorp.com noble main

extra_commands:
  - chmod 777 /opt/scripts
  - chmod 777 /opt/scripts/*
  - terraform --version
  - terraform-docs -v
  - tflint --version

copy:
  - source: scripts/
    destination: /opt/scripts/
  - source: terraform-docs
    destination: /usr/local/bin/terraform-docs
  - source: tflint
    destination: usr/local/bin/tflint

user:
  name: nonroot
  shell: /bin/bash
  home: /home/nonroot
  chown: /opt/scripts/

entrypoint: "/opt/scripts/entrypoint.bash"
cmd: "/bin/bash"

🌐 publish container image

Publikuje zbudowany obraz do gitlab registry:

🧪 test docker image

Testuje opublikowany obraz kontenera uruchamiając w nim skrypt bashowy domyślnie container_test.sh:

🧪 Przykład użycia w pipeline

---
default:
  tags:
    - process-ci

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/containers/image-builder@$COMPONENT_VERSION_CONTAINERS


🚀 build container image:
  needs:
    - job: 🕵 YAML lint
      optional: true
    - job: 🔬 Validate files (conftest)
    - job: 🕵 Set Version
      artifacts: true
  stage: build
  rules:
    - when: on_success


🌐 publish container image:
  stage: publish
  variables:
    CONTAINER_VERSION: 1.2.3
  needs:
    - job: 🕵 Set Version
      artifacts: true
    - job: 🚀 build container image
      artifacts: true
  rules:
    - when: on_success


🧪 test docker image:
  variables:
    CONTAINER_VERSION: 1.2.3
  needs:
    - job: 📍 Publish Version
      artifacts: true
    - job: 🌐 publish container image
      artifacts: true
  rules:
    - when: on_success

6 - infrastructure

6.1 - 🛠 Job template: OpenTofu

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobach

Komponent ustawia następujące zmienne w środowisku CI:

• CONTAINER_IMAGE_OPENTOFU – obraz Dockera OpenTofu (na podstawie inputs.docker_image)
• LOGO_URL – ścieżka do logo (na podstawie inputs.logo_url)
• TF_STATE_NAME – nazwa stanu OpenTofu
• TF_VAR_gitlab_token – token GitLab przekazywany do OpenTofu
• DEBUG – flaga debug

📤 Output

Joby wykonują:

1. Pobranie i wyświetlenie logo (jeżeli LOGO_URL jest ustawiony).
2. Wyświetlenie informacji o wejściowych parametrach.
3. Inicjalizację środowiska OpenTofu (tofu init) oraz odpowiednie akcje (fmt, validate, tflint, plan, apply).

Przykład logu:

===> 💾 OpenTofu Base Job - Parameters
┌──────────────────────────────┬───────────────────────────────────────────────────────┐
│ Variable                     │ Value                                                 │
├──────────────────────────────┼───────────────────────────────────────────────────────┤
│ TF_STATE_NAME                │ default                                               │
│ CONTAINER_IMAGE_OPENTOFU     │ registry.gitlab.com/pl.rachuna-net/...:2.0.0          │
└──────────────────────────────┴───────────────────────────────────────────────────────┘

🧪 Dostępne joby

🕵 opentofu fmt

Sprawdza formatowanie plików OpenTofu:

🕵 opentofu fmt:
  stage: validate
  extends: ['.infrastructure:opentofu:base']
  script:
    - tofu fmt -recursive -check

✅ opentofu validate

Wykonuje walidację konfiguracji OpenTofu:

✅ opentofu validate:
  stage: validate
  extends: ['.infrastructure:opentofu:base']
  script:
    - !reference [.infrastructure:opentofu_init]
    - tofu validate

✅ tflint

Uruchamia lintera tflint:

✅ tflint:
  stage: validate
  extends: ['.infrastructure:opentofu:base']
  script:
    - tflint

✅ terraform-docs

Generuje dokumentację modułu Terraform:

✅ terraform-docs:
  stage: validate
  extends: ['.infrastructure:terraform:base']
  script:
    - terraform-docs md . > README.md

🧪 opentofu plan

Wykonuje plan wdrożenia OpenTofu:

🧪 opentofu plan:
  stage: unit-test
  extends: ['.infrastructure:opentofu:base']
  script:
    - tofu plan

💥 opentofu apply

Wdraża infrastrukturę OpenTofu:

💥 opentofu apply:
  stage: deploy
  extends: ['.infrastructure:opentofu:base']
  script:
    - tofu apply -auto-approve

🧪 Przykład użycia w pipeline

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/infrastructure/opentofu@$COMPONENT_VERSION_INFRASTRUCTURE
    inputs:
      docker_image: $CONTAINER_IMAGE_OPENTOFU
      tf_state_name: production
      debug: "true"

6.2 - 🛠 Job template: Terraform

⚙️ Parametry wejściowe (inputs)

🧬 Zmienne środowiskowe ustawiane w jobach

Komponent ustawia następujące zmienne w środowisku CI:

• CONTAINER_IMAGE_TERRAFORM – obraz Dockera Terraform (na podstawie inputs.docker_image)
• LOGO_URL – ścieżka do logo (na podstawie inputs.logo_url)
• TF_STATE_NAME – nazwa stanu Terraform
• TF_VAR_gitlab_token – token GitLab przekazywany do Terraform
• DEBUG – flaga debug

📤 Output

Joby wykonują:

1. Pobranie i wyświetlenie logo (jeżeli LOGO_URL jest ustawiony).
2. Wyświetlenie informacji o wejściowych parametrach.
3. Inicjalizację środowiska Terraform (terraform init) oraz odpowiednie akcje (fmt, validate, tflint, plan, apply).

Przykład logu:

===> 💾 Terraform Base Job - Parameters
┌──────────────────────────────┬───────────────────────────────────────────────────────┐
│ Variable                     │ Value                                                 │
├──────────────────────────────┼───────────────────────────────────────────────────────┤
│ TF_STATE_NAME                │ default                                               │
│ CONTAINER_IMAGE_TERRAFORM    │ registry.gitlab.com/pl.rachuna-net/...:2.0.0          │
└──────────────────────────────┴───────────────────────────────────────────────────────┘

🧪 Dostępne joby

🕵 terraform fmt

Sprawdza formatowanie plików Terraform:

🕵 terraform fmt:
  stage: validate
  extends: ['.infrastructure:terraform:base']
  script:
    - terraform fmt -recursive -check

✅ terraform validate

Wykonuje walidację konfiguracji Terraform:

✅ terraform validate:
  stage: validate
  extends: ['.infrastructure:terraform:base']
  script:
    - !reference [.infrastructure:terraform_init]
    - terraform validate

✅ tflint

Uruchamia lintera tflint:

✅ tflint:
  stage: validate
  extends: ['.infrastructure:terraform:base']
  script:
    - tflint

✅ terraform-docs

Generuje dokumentację modułu Terraform:

✅ terraform-docs:
  stage: validate
  extends: ['.infrastructure:terraform:base']
  script:
    - terraform-docs md . > README.md

🧪 terraform plan

Wykonuje plan wdrożenia Terraform:

🧪 terraform plan:
  stage: unit-test
  extends: ['.infrastructure:terraform:base']
  script:
    - terraform plan

💥 terraform apply

Wdraża infrastrukturę Terraform:

💥 terraform apply:
  stage: deploy
  extends: ['.infrastructure:terraform:base']
  script:
    - terraform apply -auto-approve

🧪 Przykład użycia w pipeline

include:
  - component: $CI_SERVER_FQDN/pl.rachuna-net/cicd/components/infrastructure/terraform@$COMPONENT_VERSION_INFRASTRUCTURE
    inputs:
      docker_image: $CONTAINER_IMAGE_TERRAFORM
      tf_state_name: production
      debug: "true"