Skip to main content

Use the Pillars pipeline in your project

How-ToPublicInterface: GitLab, CI/CD settings

When you need this

Apps onboarded through the Console have the Pillars pipeline pre-wired automatically. Use this guide if you're integrating the pipeline into an existing repo that was not created through the Console, or if you need to understand what the Console configures on your behalf.

Before you begin

  • Your repo is hosted on GitLab on the platform
  • You have at least Developer role on the GitLab project
  • Your Platform Engineer has confirmed the pipeline project (getting-started/pillars/pipeline) is accessible from your GitLab instance

Step 1 — Add the pipeline include

Create or open .gitlab-ci.yml in the root of your repo. Add:

include:
- project: "getting-started/pillars/pipeline"
ref: main
file: "pipeline/pipeline.yaml"

This is the only required change. On your next commit, GitLab fetches the full Pillars of Creation pipeline definition and runs it. No scanner installation or configuration needed.

Step 2 — Enable Git push for the job token

The semantic-release job in the release stage needs permission to push version bumps and tags back to your repo. By default it uses the CI_JOB_TOKEN — you must grant it push access:

  1. In your GitLab project, go to Settings → CI/CD
  2. Expand Job token permissions
  3. Under Additional permissions, enable Allow Git push requests to the repository

Without this, the semantic-release job will fail when it tries to push the changelog commit and version tag. All other pipeline stages are unaffected.

Step 3 — Create the release token

The attach-artifacts job needs a Project Access Token to upload build artifacts to the GitLab Release. Create one:

  1. Go to Settings → Access Tokens
  2. Click Add new token
  3. Set role to Developer and scope to api
  4. Copy the generated token value
  5. Go to Settings → CI/CD → Variables
  6. Add a new variable: name RELEASE_TOKEN, value = your token, type = Masked

If RELEASE_TOKEN is not set, the attach-artifacts job fails — but this only affects attaching artifacts to releases. The security scanning stages (Pillars 2 and 3) are unaffected.

Step 4 — Verify framework detection

Push a commit. In GitLab, open CI/CD → Pipelines and watch the pipeline run. In the dependencies stage, check which jobs activated:

If you see this jobIt detected
npm-dependenciespackage-lock.json found → Node.js
gradle-dependenciesbuild.gradle found → Java/Gradle
poetry-dependenciespyproject.toml + poetry.lock found → Python
cmake-dependenciesCMakeLists.txt found → C++
(no framework job)Common framework — container-only pipeline

If a framework was detected incorrectly (e.g., your repo has a package-lock.json for tooling but isn't a Node.js app), disable it:

include:
- project: "getting-started/pillars/pipeline"
ref: main
file: "pipeline/pipeline.yaml"

variables:
NPM: "false" # disable Node.js jobs

Available flags: NPM, GRADLE, POETRY, CPP — set to "false" to disable.

Step 5 — (Optional) Configure Kustomize for auto image-tag updates

If your deployment manifests are managed with Kustomize in a separate repo, the pipeline can automatically update the image tag after each successful build. Add these variables to your .gitlab-ci.yml:

variables:
KUSTOMIZE_IMAGE_UPDATE: "true"
KUSTOMIZE_PROJECT: "your-org/your-manifests-repo"
KUSTOMIZE_BRANCH: "main"
KUSTOMIZE_FILES: "overlays/dev/kustomization.yaml"

On each successful publish stage, the pipeline opens an MR in your manifests repo updating the image tag to the newly built version. This is the GitOps promotion trigger — ArgoCD picks up the MR merge and syncs the new image to the cluster.

Verify the pipeline is working

After your first commit with the include block:

  1. GitLab → CI/CD → Pipelines — confirm a pipeline ran
  2. Check the code-analyze stage — all static analysis jobs should appear
  3. If a Dockerfile is present: check artifact-build for container-build, then artifact-analyze for Grype and Trivy scans
  4. Check Build → Artifacts — confirm the SBOM and Body of Evidence (BoE) reports are attached

A passing pipeline with no Critical findings means the artifact is cleared for promotion.

Learn more