Skip to content

gitlab.md

Latest commit

 

History

History
118 lines (93 loc) · 4.16 KB

gitlab.md

File metadata and controls

118 lines (93 loc) · 4.16 KB
Raw

Getting Started: GitLab CI

This is the happy path to a working Brik pipeline on a GitLab instance. For the full integration reference (runner images, pipeline variables, cache relocation, coverage reports, troubleshooting), see platforms/gitlab.md.

Prerequisites

  • A GitLab instance where you can create projects.
  • A GitLab Runner with the Docker executor.
  • Access to ghcr.io/getbrik/* images, or a mirror of brik-images on your own registry.

1. Push the Brik runtime

Create a brik/brik project on your GitLab instance and push the Brik source:

git clone https://github.com/getbrik/brik.git
cd brik
git remote add gitlab http://your-gitlab.example.com/brik/brik.git
git push gitlab main --tags

2. Push the GitLab templates

Create a brik/gitlab-templates project and push the shared-libs/gitlab directory:

cd shared-libs/gitlab
git init -b main
git add -A
git commit -m "Initial commit"
git remote add origin http://your-gitlab.example.com/brik/gitlab-templates.git
git push -u origin main
git tag v0.7.0          # pin to the Brik release you pushed in step 1
git push origin v0.7.0

3. Add the bootstrap file to your project

Add a .gitlab-ci.yml to your project root. This file is the GitLab adapter wiring: a thin entry point that hands your run to Brik. It carries no delivery logic of its own; the pipeline itself is defined by the brik.yml you add next (step 4), identical on every platform.

include:
  - project: 'brik/gitlab-templates'
    ref: v0.7.0                          # the gitlab-templates tag from step 2
    file: '/templates/brik-integrate.yml'

On GitLab this materializes as a single classic pipeline: a brik-plan job computes the execution plan, then every stage job consults it and skips itself when the plan marks the stage not-applicable; for example, a docs-only commit shows the skipped stages as green "skipped (per plan)" jobs without running their work. See platforms/gitlab.md for the full job graph.

4. Add a brik.yml

Add a brik.yml to your project root. The minimum is two fields:

version: 1
project:
  name: my-app
  stack: node

brik init --platform gitlab can scaffold both files for you; see getting-started/local.md.

That is it. Your next push runs the full fixed flow: Init detects the stack and resolves the runner image, then Build, the parallel Lint / SAST / Scan / Test group, Package, Container Scan, Deploy, and Notify run in order. Every run produces an aggregate report.

Next steps: Enable supply-chain security

Once CI is working, to use the CD flow with attestation verification:

  1. Create an infrastructure referential (endpoints, credentials, policies, trust material) and mount it on the runner at /etc/brik/infra. See artifact attestation.
  2. Select CI or CD per run with include:rules: one repository, two flows, discriminated by the BRIK_DEPLOY_VERSION trigger variable:
include:
  - project: 'brik/gitlab-templates'
    ref: v0.7.0
    file: '/templates/brik-integrate.yml'
    rules:
      - if: '$BRIK_DEPLOY_VERSION !~ /.+/'
  - project: 'brik/gitlab-templates'
    ref: v0.7.0
    file: '/templates/brik-deploy.yml'
    rules:
      - if: '$BRIK_DEPLOY_VERSION =~ /.+/'

A push or tag runs the CI flow; a "Run pipeline" (or API trigger) with BRIK_DEPLOY_VERSION and BRIK_DEPLOY_ENVIRONMENT runs the CD flow, which resolves the version to a digest, verifies the attestations and checks the promotion journal before deploying. See platforms/gitlab.md for the full setup.

Other next steps