Gitlab Ci
# This file is executed by the acceptance test suite (living documentation)
#
# Rules:
# - Step definitions live in: <test-source-root>/steps/ (or equivalent per language)
# - Keep scenarios focused: one behaviour per scenario.
# - Use exact terms from specs/glossary.md.
Feature: Properties of GitLab CI/CD Pipelines
As a software engineer
I want all GitLab CI/CD pipelines to provide a certain set of functionalities
So that I can efficiently and reproducably build, tests, deploy, etc.
Scenario: Jobs of all GitLab pipelines, regardles of language or artifact type
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | tool |
| cpp | library |
| cpp | service |
| go | tool |
| go | library |
| go | service |
| java | library |
| java | service |
Then .gitlab-ci.yml contains at least the following jobs:
| Job | Purpose |
| build | Debug build |
| release-build | Release build |
| commit-lint | Ensures commit messages follow recommendations |
| lint | Static code checks |
| test | Execute all unit/component tests on debug builds (JUnit XML report) |
| scan | Scans repository for secrets and vulnerabilities |
| coverage | Determines test coverage (Cobertura format) |
| pages | Builds documentation HTML site and publishes GitLab Pages |
Scenario: The source scan knows about the dependency cache the pipeline itself creates
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | tool |
| cpp | library |
| cpp | service |
| go | tool |
| go | library |
| go | service |
| java | library |
| java | service |
| typescript | frontend-react |
Then every .gitlab-ci.yml source scan excludes the directories the pipeline caches
And no .gitlab-ci.yml source scan uses --offline-scan
And every .gitlab-ci.yml source scan of a Maven project points Trivy at the cached local repository
And every .gitlab-ci.yml source scan of a Maven project needs a job that resolves dependencies first
Scenario: Jobs of GitLab pipelines specific to CLI tools and services
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | tool |
| cpp | service |
| go | tool |
| go | service |
| java | service |
Then .gitlab-ci.yml contains at least the following jobs:
| Job | Purpose |
| build-image | Builds debuggable Docker image (manual only) |
| push-image | Pushes commit-SHA-tagged Release image (Merge-to-main tier) |
| scan-image | Scans target Docker images for secrets and vulnerabilities |
And every .gitlab-ci.yml job scanning a registry image passes registry credentials
Scenario: Jobs of GitLab pipelines specific to C++ and Java libraries
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | library |
| java | library |
Then .gitlab-ci.yml contains at least the following jobs:
| Job | Purpose |
| package | Create Conan package (C++) or Maven package (Java) |
| publish | Pushes package to GitLab Conan/Maven artifactory |
Scenario: C++ Release-tier jobs build and test on musl, matching the dual-platform ADR
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | tool |
| cpp | library |
| cpp | service |
Then the .gitlab-ci.yml jobs use these images:
| Job | Image |
| release-build | registry.gitlab.com/hzahnlei/build-images/cpp-build-musl:1.2.0 |
| release-test | registry.gitlab.com/hzahnlei/build-images/cpp-build-musl:1.2.0 |
| release-coverage | registry.gitlab.com/hzahnlei/build-images/cpp-build-musl:1.2.0 |
Scenario: C++ services run BDD acceptance scenarios over HTTP (Behave)
Given a generated .gitlab-ci.yml for:
| Languange | Artifact Type |
| cpp | service |
Then .gitlab-ci.yml contains at least the following jobs:
| Job | Purpose |
| bdd-test | Runs Behave feature files against a running instance |