GitOps Pro Templates

What You Get:

Seven complete GitLab CI/CD pipeline templates, each with a README, a machine-readable descriptor, and example configuration files.

1. Simple Pipeline — a single Dockerfile to production. Seven stages: validate, lint, test, security, build, scan, release. One manual approval gate before anything is pushed. The right starting point, and the template the other three container pipelines are built from.
2. Multi-Container Pipeline — 2 or more containers in one repository, built concurrently with GitLab's parallel.matrix. Per-service image tags, per-service Trivy reports and SBOMs, per-service manifest paths. Add a service by adding three lines to the matrix.
3. Multi-Stage Simple Pipeline — one container, two gates. Feature branch → approve → development (:sha-dev, k8s/dev/) → approve → production (:sha, k8s/prod/). Separate SBOMs per environment for audit.
4. Multi-Stage Multi-Container Pipeline — the combination: parallel matrix builds with the dual-gate progressive rollout, and dev/prod manifest paths for every service. This is the one for microservices under change control.
5. Simple Terraform — purpose-built for IaC. terraform validate, fmt, TFLint, then tfsec + Checkov + Trivy config scanning, then a full plan published as a reviewable artifact and rendered in GitLab's Terraform widget, then a manual gate before apply. GitLab-managed HTTP state works out of the box with no configuration. Optional Infracost estimation.
6. Simple Manifest — for Kustomize repos with no Dockerfile. Renders your overlay, schema-validates every resource with kubeconform against your cluster's API version (CRDs included, via the datreeio catalog), scans for misconfigurations and secrets, and publishes the rendered YAML as an artifact so a reviewer sees exactly what ArgoCD will sync. No apply stage — the deploy is ArgoCD pulling from your default branch.
7. Linux Package (new in 4.1.0) — for software that becomes a package on a machine rather than an image in a registry. Builds Go, Python or Node sources (or ships files only), assembles a versioned .deb, gates it with the same scanner set the container templates use, and publishes it to the GitLab generic package registry for configuration management to install at a pinned version. Authenticated by CI_JOB_TOKEN — there is no stored credential to rotate or leak. Note the deliberate difference from the container templates: there is no manual approval job. A merge to your default branch publishes once the gates pass, because the merge request is the review and the version is immutable. Set ENABLE_PUBLISH: "false" if you want to publish from tags only.

Also in the box

• No privileged runners. Container builds use Kaniko — no Docker socket, no privileged mode. Pushes use crane, so the release jobs need no daemon either.
• Images and tools are version-pinned. Pinning only the job images is not enough: with an unpinned linter a job can pass, then fail on an unchanged commit, because the tool shipped a new rule overnight. That is not a flaky test, it is a non-reproducible pipeline.
• GitOps built in. Updates your Kubernetes manifest with the new image reference and commits it back with [skip ci], with rebase-and-retry on contention. ArgoCD or Flux takes it from there.
• CycloneDX SBOMs, optionally committed to security/ for compliance.
• Coverage reporting wired to GitLab's UI, with an optional threshold.
• Docs-only optimization — a README change does not run a container build.
• A machine-readable template.yaml per template — plain JSON Schema for every input, plus an explicit parameter-to-CI-variable mapping. Anything that can render a form from JSON Schema can drive these templates, so they drop into an internal developer platform without a human reading a README first. Vendor-neutral by design; no dependency on any platform product.
• CI-VARIABLES.md — exactly which CI/CD variables to create, which of Masked/Protected to tick and why, with placeholder values throughout. The honest headline: on the GitLab Container Registry with no GitOps commit, you need to create none.

What's new in v4.1.0

• The linux-package template — the seventh, described above.
• make ci-lint — validates every template against GitLab's own CI Lint API. yamllint proves a file is well-formed YAML; it does not prove GitLab will accept it. An unquoted script line containing ": " is valid YAML that parses to a mapping, and GitLab rejects a job whose script is not a string — producing a pipeline with no jobs at all. Four templates shipped in exactly that state. Fixed, and now gated by asking GitLab itself.
• sca:osv no longer fails a repository with no lockfiles.
• The assembled .deb no longer ships world-writable paths — and the first version of that fix, which forced every directory to 0755 and would have published a deliberate 0750 directory as world-readable, was corrected before release.
• Every template's documentation now matches its pipeline. Six of seven READMEs still described v3.0: documented defaults that contradicted the shipped values, quick-start cp commands naming files that 4.0.0 removed, and three scanners that shipped in 4.0.0 and appeared in no README.

Upgrading from 4.0.0 requires nothing — no pipeline behaviour changed.

Requirements

• GitLab 15.0+ (18.4+ recommended)
• Standard GitLab runners — no privileged mode required
• Language support where relevant: Python 3.12+, Node 20+, Go 1.21+

License

Commercial. Use, modify and deploy across unlimited projects, internally and for clients, including commercially. Redistribution or resale of the templates themselves is not permitted. Full terms in LICENSE inside the download.

What you download

A single .tar.gz containing all seven templates, per-template READMEs and template.yaml descriptors, example configurations (.flake8, .bandit, .hadolint.yaml, .gitleaks.toml, .tflint.hcl, .yamllint, plus example pipelines per language), README.md, CI-VARIABLES.md, TEMPLATE-SPEC.md, CHANGELOG.md and LICENSE. SHA-256 and MD5 checksum files are published alongside the archive so you can verify the download before extracting it.