# Gitlab CI Knowledge Patch > GitLab CI/CD - Skill: `nevaberry/gitlab-ci-knowledge-patch` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add nevaberry/gitlab-ci-knowledge-patch` - Raw SKILL.md: https://api.skillmd.com/api/skills/nevaberry/gitlab-ci-knowledge-patch/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: nevaberry (https://skillmd.com/u/nevaberry) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/nevaberry/gitlab-ci-knowledge-patch --- # GitLab CI/CD Knowledge Patch Use this skill when configuring GitLab pipelines, runners, security features, CI/CD inputs, Catalog components, or GitLab upgrades. Start with the quick reference for high-impact compatibility decisions, then open the topic file that matches the task. ## Reference index | Reference | Topics | | --- | --- | | [Duo agents and flows](references/duo-agents-and-flows.md) | Duo CLI, custom and foundational flows, dependency remediation, CI Expert Agent, failure fixing | | [Pipeline configuration](references/pipeline-configuration.md) | AST pipeline selection, array inputs, merge trains, scheduled pipeline policies | | [Runner, Catalog, and analytics](references/runner-catalog-and-analytics.md) | Runner telemetry and timeouts, Catalog usage, project analytics | | [Security, secrets, and job tokens](references/security-secrets-and-job-tokens.md) | Job-token permissions and pushes, Secrets Manager, security fixes | | [Upgrade planning](references/upgrade-planning.md) | Required stops, databases, registry, operating systems, bundled services, Helm, Geo, package cleanup | ## Quick reference: upgrade blockers and removals ### Plan every required upgrade stop For a GitLab 19 upgrade, include the required stops at `19.2`, `19.5`, `19.8`, and `19.11`. Read all intervening release notes, including notes for the installation method in use. ### Upgrade PostgreSQL before GitLab 19 GitLab 19.0 requires PostgreSQL 17 for every installation method. Upgrade a packaged PostgreSQL 16 server or an external PostgreSQL deployment before installing GitLab 19. ### Replace unsupported platforms and data services - Replace external Redis 6 with Redis 7.0 or later or Valkey 7.2 before the upgrade. The Redis bundled with the Linux package is already version 7. - Move off Ubuntu 20.04 packages; GitLab 18.11 is their final release. - Linux package installations on openSUSE Leap 15.6, SLES 12.5, or SLES 15.6 must move to Docker for GitLab 19. - The Helm chart and Operator no longer bundle Bitnami PostgreSQL, Bitnami Redis, or MinIO. Configure external services before upgrading. ### Remove or externalize bundled services - Move bundled Mattermost users to standalone Mattermost and remove or comment every `mattermost[...]` key in `/etc/gitlab/gitlab.rb` before reconfiguration. - Deploy Spamcheck separately; GitLab 19.0 removes it from both the Linux package and Helm chart, with no data migration required. - Prepare Helm installations for Gateway API with Envoy Gateway, the new default. Bundled NGINX Ingress can still be explicitly enabled for now. ### Migrate registry storage configuration The legacy `s3` storage driver is removed and aliased to `s3_v2`. For non-AWS S3-compatible storage, make `regionendpoint` a complete URI. Set `checksum_disabled` when the backend rejects enhanced upload checksums, but confirm deletion compatibility because deletion still sends CRC32. ```ruby registry['storage'] = { 's3_v2' => { 'accesskey' => '', 'secretkey' => '', 'bucket' => '', 'region' => '', 'regionendpoint' => 'https://storage.example.com', 'pathstyle' => true, 'checksum_disabled' => true } } ``` ### Avoid the affected patch releases - Upgrade self-hosted Duo directly to 19.2.1 or later. A direct Linux package upgrade to 19.2.0 can clear local service endpoints and related settings. - Upgrade Geo primary and secondary sites to 19.0.2 or later to avoid silently omitting OCI image-index tags on secondaries. - On affected 19.2 self-managed systems, install 19.2.1 immediately. Equivalent fixed releases are 19.1.3 and 19.0.5. See [Upgrade planning](references/upgrade-planning.md) for recovery steps, registry metadata behavior, exact package cleanup, and installation-specific details. ## Quick reference: pipeline configuration ### Choose AST merge-request behavior explicitly Set `AST_ENABLE_MR_PIPELINES` to select merge-request or branch pipelines when a merge request is open. Stable security templates default to branch pipelines, while Latest templates default to merge-request pipelines. ```yaml variables: AST_ENABLE_MR_PIPELINES: "true" ``` This applies to all security scanning templates except `API-Discovery.gitlab-ci.yml`; API Discovery defaults to branch pipelines. ### Address individual array inputs Use `[]` to interpolate one element of an array input directly. ```yaml spec: inputs: targets: type: array default: [staging, production] --- show-first-target: script: - echo "$[[ inputs.targets[0] ]]" ``` The Run pipeline UI can also collect multiple options for an array input and combine them into one array for the pipeline run. ### Control merge-train concurrency Premium and Ultimate self-managed or Dedicated installations can configure a per-project or instance-wide merge-train limit instead of the former fixed maximum of 20 pipelines. Use `1` to process merge requests one at a time against a clean target branch. ### Enforce scheduled pipeline policies centrally Define daily, weekly, or monthly schedules once in a security policy project. Each policy launches a separate pipeline across projects in scope without editing their `.gitlab-ci.yml`, with time-zone, execution-window distribution, and target-branch controls. ## Quick reference: tokens, secrets, and security ### Prefer least-privilege job tokens Fine-grained job-token permissions can restrict a CI job token to named project resources instead of inheriting the triggering user's full permissions. The beta applies to GitLab.com and self-managed projects in all tiers. ### Gate cross-project job-token pushes For a `CI_JOB_TOKEN` push to another project, the target must opt in and the pipeline starter must have at least the Developer role there. The `allow_push_to_allowlisted_projects` feature flag is also required and is disabled by default. ### Request Secrets Manager access explicitly GitLab Secrets Manager is an open beta for Premium and Ultimate customers on GitLab.com and self-managed installations. Project and group Owners can scope stored secrets to their project or group; pipeline jobs receive only secrets they explicitly request. Treat the service as beta and assess production readiness accordingly. ### Prioritize the security patch The 19.2.1 release fixes 13 vulnerabilities, including three high-severity issues affecting Workhorse information access, pipeline schedule input authorization, and merge-request discussion denial of service. It also fixes authorization and policy-enforcement paths involving protected branches, pipeline reports, Duo Code Review, and Duo Workflows. ## Quick reference: runners and visibility ### Export Runner job telemetry GitLab Runner can negotiate instrumentation, export through an OTLP client, and emit its initial `job_execution` span. Runner configuration also exposes the prepare-stage timeout. ### Inspect component consumers Ultimate customers can view the projects consuming each CI/CD Catalog component, their chosen versions, and whether those versions are current. Outdated consumers appear first. ### Use project analytics on Dedicated The limited-availability project CI/CD analytics view on GitLab Dedicated shows pipeline performance trends and reliability metrics in the project UI. ## Quick reference: agents and flows ### Use terminal and CI/CD sessions GitLab Duo CLI is generally available through `glab` or as a standalone tool. It supports interactive chat and headless CI/CD use with project, pipeline, and agent context. Administrators on self-managed and Dedicated installations can disable it. ### Reuse controlled workflows Custom flows are YAML-defined reusable workflows managed from a project or the AI Catalog. They can coordinate multiple agents, approval or feedback checkpoints, visibility, validated configuration, identities, and lifecycle or pipeline triggers. ### Route failures to focused fixes The Fix CI/CD Pipeline Flow classifies failures, follows child-pipeline failures, honors project behavior from `AGENTS.md`, and can return code suggestions when relevant files are already in a merge request diff. See [Duo agents and flows](references/duo-agents-and-flows.md) for handoffs, dependency remediation, the CI Expert Agent, tool controls, and flow execution details.