On May 21, 2026, GitLab 19.0 was released with the following features.
We’d also like to announce this month’s Notable Contributor: Norman Debald!
We are excited to recognize Norman, a Level 3 contributor with more than 40 merged improvements across GitLab since joining in May 2022.
In previous versions of GitLab, you could only define custom review instructions for GitLab Duo at the project level. Teams working across many projects in the same group had to duplicate the same instructions in every project.
Now you can configure shared custom review instructions for an entire group and its subgroups.
Select a project in your group to use as a template. When GitLab Duo performs a code review, it combines the group-level .gitlab/duo/mr-review-instructions.yaml file with any instructions defined in the individual project.
Both Code Review Flow and GitLab Duo Code Review support group-level custom instructions.
Previously, work item types could be either an Issue or a Task. You can now configure custom work item types in a project to match the way your team plans and tracks work.
You can create or rename types to User Story, Bug, or Maintenance. Each work items displays with it’s type name and a unique icon. The new types support custom fields and status lifecycles, and appear in your saved views and issue boards. Type configuration in the top-level group (GitLab.com) or organization (GitLab Self-Managed) cascades down to all projects.
You can also control which types are available for each project. Enable or disable a type across all projects at once, or let individual projects manage their own type visibility. When you disable a type in a project, existing work items are not affected.
In previous versions of GitLab, the GitLab Secrets Manager was available only to a closed beta cohort. Most teams relied on external services such as HashiCorp Vault or AWS Secrets Manager.
The GitLab Secrets Manager is now available in open beta for Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. When the GitLab Secrets Manager is enabled, project and group Owners can store, retrieve, and reference CI/CD secrets in GitLab. Secrets are scoped to a project or group and are accessible to only pipeline jobs that explicitly request them.
During open beta, GitLab Secrets Manager follows the beta support policy and might not be ready for production use.
To share feedback, see issue 598100.
GitLab Duo Developer now supports multiple trigger methods: assign it to an issue, select
Generate MR, or @mention it in any issue or MR discussion thread to turn feedback,
To-do items, and design questions into code changes, follow-up MRs, or research summaries.
With AGENTS.md and agent-config.yml
configured, GitLab Duo Developer runs your tests and checks before committing. After a top-level
group or instance administrator enables the Developer Flow, GitLab automatically adds mention and assign triggers
to eligible projects.
The GitLab SBOM-based dependency scanner is now generally available. Maven, Gradle, and Python projects now have complete visibility into vulnerabilities across their full dependency tree, including vulnerable packages introduced transitively, not just those declared directly.
The analyzer now includes automatic dependency resolution for Maven, Gradle, and Python projects. When a lockfile or resolved dependency graph is not present, the analyzer automatically invokes tooling to resolve the full transitive dependency graph before scanning. Dependency resolution is enabled by default and requires little-to-no additional configuration beyond including the v2 Dependency Scanning template.
For projects where dependency resolution is not possible, the analyzer falls back to
manifest scanning. It parses pom.xml, requirements.txt, build.gradle, and
build.gradle.kts to identify direct dependencies. Manifest scanning ensures teams
always get a starting point for vulnerability coverage, even for projects without
lock or build files.
Manifest scanning is enabled by default and returns direct dependencies only. For full transitive coverage, enable dependency resolution or provide a dependency lockfile or graph export manually.
Starting in GitLab 19.0, GitLab Duo Core moves to usage-based billing. Code Suggestions in the Web IDE and desktop IDEs now consume GitLab Credits.
GitLab Duo Chat is also changing. For GitLab Duo Core users, Chat is now agentic and runs on GitLab Duo Agent Platform. To use GitLab Duo Chat in the GitLab UI or desktop IDEs, enable GitLab Duo Agent Platform for your instance or top-level group.
You can now filter exact code search results by repository. With the repo: syntax,
you can directly scope your search query to specific repositories or repository patterns
without having to go to individual projects.
For example, searching for def authenticate repo:my-group/my-project returns results
only from that repository. You can also use partial paths or patterns to match multiple repositories.
You can now configure flows and external agents to run on the Merge request ready event.
When a draft merge request is marked as ready for review, GitLab Duo automatically runs the flow or external agent.
To configure a trigger, go to AI > Triggers in your project.
This feature is behind the merge_request_ready_flow_trigger feature flag, disabled by default.
Claude Opus 4.7 is now available in GitLab Duo Agent Platform. Opus 4.7 delivers meaningful improvements to complex, multistep tasks that require sustained reasoning, precise instruction following, and self-verification before surfacing results. This includes flows supporting CI/CD pipelines, code review, vulnerability resolution, and more.
GitLab Duo Agent Platform Self-Hosted is now compatible with Gemini models. Gemini models support multiple flows, including the Code Review Flow, SAST Vulnerability Resolution Flow, Fix CI/CD Pipeline Flow, and more.
GitLab Duo Agent Platform now supports additional open source models for self-hosted deployments, including Devstral 2 123B, GLM-5.1-FP8, and others. This helps customers power agentic workflows across a variety of environments, including offline and network-restricted deployments.
Before GitLab Duo Agentic Chat can use a tool on your behalf, it requires your approval. Each tool invocation requires a separate approval.
Now, you can approve a trusted tool once for an entire session and streamline your workflows.
Administrators control whether tool approval for sessions is available. The following settings cascade from instance to group to project:
Groups and subgroups can modify the setting unless an administrator sets it to Always off.
The default setting is Off by default, ensuring each tool invocation requires explicit approval unless an administrator changes it.
In previous versions of GitLab, you had to resolve merge conflicts manually in the GitLab UI or from the command line, even for straightforward cases.
Now GitLab Duo can autonomously analyze merge conflicts, edit the conflicting files, create a commit, and push to the source branch. Trigger conflict resolution from the Resolve conflicts page or directly from the merge request widget. When complete, GitLab Duo posts a summary comment so reviewers can see what changed.
GitLab Duo respects branch protection rules and does not force-push to protected branches.
This feature is in beta and is gated behind the mr_ai_resolve_conflicts feature flag,
enabled by default.
Top-level group Owners can now restrict the AI Catalog to show only agents and flows owned by projects within their group hierarchy. This blocks agents, external agents, or flows not in this hierarchy from being visible or enabled by any user in that group.
Free tier users on GitLab Self-Managed can now unlock the full power of GitLab Duo Agent Platform, no Premium or Ultimate subscription required. Choose your monthly credit amount, commit to an annual term, and get instant access to AI-powered development tools. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.
Administrators can now define centralized network policies for GitLab Duo Agent Platform remote flows directly in Settings. Top-level group administrators on GitLab.com, and instance administrators on GitLab Self-Managed and Dedicated, can configure organization-wide domain denylists and allowlists that projects inherit automatically. An additional setting controls whether projects can extend the approved domain list with custom entries. Policies are enforced at runtime across all remote flows, giving security and platform teams a consistent governance layer for agent network egress.
The minimum supported version of PostgreSQL is now version 17. If you use the packaged PostgreSQL 16, upgrade the packaged PostgreSQL server before installing GitLab 19.0.
Ubuntu 20.04 reached end of standard support in May 2025. From GitLab 19.0, Linux packages are no longer provided for Ubuntu 20.04. GitLab 18.11 is the last release with packages for this distribution. Before upgrading to GitLab 19.0, migrate to Ubuntu 22.04 or another supported operating system.
Support for Redis 6 is removed in GitLab 19.0. If you use an external Redis 6 deployment, migrate to Redis 7.2 or Valkey 7.2 before upgrading. The bundled Redis included with the Linux package has used Redis 7 since GitLab 16.2 and is not affected.
Bundled Mattermost is removed from the Linux package in GitLab 19.0. If you currently use the bundled Mattermost, refer to Migrating from the Linux package to Mattermost Standalone for migration instructions. Customers not using the bundled Mattermost are not impacted.
Linux package support for SUSE distributions ends in GitLab 19.0, which affects openSUSE Leap 15.6, SUSE Linux Enterprise Server 12.5, and SUSE Linux Enterprise Server 15.6. GitLab 18.11 is the last version with Linux packages for these distributions. To continue to use SUSE distributions, migrate to a Docker deployment of GitLab.
Spamcheck is removed from the Linux package and GitLab Helm chart in GitLab 19.0. Customers not currently using Spamcheck are not impacted. If you use the bundled Spamcheck, you can deploy it separately using Docker. No data migration is required.
Gateway API with Envoy Gateway becomes the default networking configuration in the GitLab Helm chart in GitLab 19.0, replacing NGINX Ingress which reached end-of-life in March 2026. If migration to Envoy Gateway is not immediately feasible, you can explicitly re-enable the bundled NGINX Ingress, which remains available until its planned removal in GitLab 20.0. This change does not impact the NGINX used in the Linux package, or Helm chart instances using an externally managed Ingress or Gateway API controller.
The bundled Bitnami PostgreSQL, Bitnami Redis, and MinIO charts are removed from the GitLab Helm chart and GitLab Operator in GitLab 19.0 with no replacement. These components were intended only for proof-of-concept and test environments and are not recommended for production use. If you run an instance with any of these bundled services, follow the migration guide to configure external services before upgrading to GitLab 19.0.
For organizations managing large numbers of users through SCIM, deprovisioning group members
could time out and return 500 errors. SCIM DELETE and PATCH requests now return a
success response immediately. Membership removal is handled asynchronously, so identity
providers and SCIM clients receive consistent success responses.
The in-product GitLab Credits dashboard now supports product filtering, date range selection, and Secrets Manager usage visibility.
You can filter usage by product (including GitLab Duo and Secrets Manager) and date range, see a daily usage chart across selected products, and review per-user attribution with a Usage control status column.
The dashboard also includes usage from service accounts so automated activity is reflected in per-user attribution, and surfaces non-billable and beta events such as Secrets Manager Open Beta activity. This gives you a complete view of credit consumption in your organization.
In previous versions of GitLab, the Credits dashboard showed only the current billing month, so you couldn’t compare trends, audit a usage spike after the fact, or build a budget conversation around prior consumption. Now you can navigate to prior billing months in the Credits dashboard.
Auto remediation for dependencies is now available as an experiment in GitLab 19.0. When dependency scanning detects a vulnerable Ruby dependency with a known fix, GitLab automatically opens a merge request to update it to a safe version without human input. Only Ruby projects are supported in the experiment.
After each pipeline, GitLab identifies the highest-severity vulnerability with an available patch or minor version upgrade. GitLab generates the manifest file change and opens a merge request through a service account. The merge request then goes through your project’s standard review and approval workflow.
During the experiment, up to three auto-remediation merge requests can be open per project at a time.
To share feedback or request to try out the experiment make a comment on epic 600511.
To enable the experiment on your project, a GitLab team member must enable the dependency_management_auto_remediation feature flag for your project.
GitLab 18.11 introduced security configuration profiles for SAST and secret detection. Now, dependency scanning is also available with the Dependency Scanning - Default profile. This profile gives you a unified control surface to apply standardized SCA coverage across all of your projects without editing a single CI/CD configuration file.
The profile activates two scan triggers:
GitLab dependency scanning using SBOM now automatically generates a dependency graph (gradle.graph.txt)
for Gradle projects. Previously, Gradle dependency scanning required
you to generate a dependency graph
manually as part of your build. Now, when a graph file is not available, the analyzer
generates one automatically, removing this manual step for Java and Kotlin projects using Gradle.
API security vulnerability reports now include remediation guidance for each finding. Previously, API security testing identified vulnerabilities but provided no guidance on how to fix them. Developers had to research remediation steps independently. Now, each finding includes vulnerability-specific remediation steps and references to relevant OWASP and CWE identifiers directly in the vulnerability report.
Remediation guidance is now included for the following checks:
Merge requests include a new Reports tab that shows all findings from security scans, license compliance results, and code quality reports for the pipeline.
GitLab bot comments in the activity feed are still available to view any policy violations that prevent the merge request from being merged.
CI/CD inputs now have improved support for working with arrays.
Use the array index operator [] to access specific elements within array inputs.
This enhancement provides more flexible and powerful input interpolation capabilities in your pipeline configurations,
enabling you to reference individual array items directly without additional processing steps.
Previously, you could only select a single value when selecting input options in the UI, limiting flexibility for pipelines with more complex options.
Now when you run a pipeline with inputs from the UI, you can select multiple values from a dropdown list
and the selected values are combined into an array, for example ["option1","option2"].
This makes it easy to restart services on multiple instances, build multiple Docker images,
run tests with multiple tag combinations, or perform any operation across multiple targets
in a single pipeline run.
When you manage a CI/CD component in the GitLab Catalog, usage details are critical for managing upgrades, enforcing compliance, and communicating breaking changes. You need to know which projects use your components, and which versions they are using. Previously, this information was not available, making it difficult to notify the right maintainers, plan deprecations safely, or ensure projects stay current with the latest security patches.
The component usage details view in the catalog resource page now shows exactly which projects use each component, the version they are running, and whether they are on the latest version or an outdated one. Projects using older versions are surfaced at the top, so you can prioritize outreach, drive adoption of security fixes, and ensure a smooth upgrade path across your organization.
In previous versions of GitLab, you couldn’t change the maximum of 20 parallel pipelines in a merge train, which forced you to either overwhelm your runners or skip merge trains entirely. Now you can configure the parallel pipeline limit per merge train to balance runner load and merge throughput. You can set the limit per project or instance-wide. Setting the limit to 1 means each merge request runs one at a time, against a clean target branch.
Thanks to Norman Debald (@Modjo85) for this community contribution.
In previous versions of GitLab, the default title for a new merge request came from the source branch or first commit, and you couldn’t enforce a consistent naming convention across your project.
Now you can configure a default merge request title template per project. Templates
support variables for the source branch, target branch, first commit subject, linked
issue ID, issue title, and a human-readable version of the source branch name. For example, the template
Resolve %{issue_id} "%{issue_title}" produces titles like Resolve 123 "Fix login bug".
You can still edit the title before creating the merge request.
The existing X-Gitlab-Token header sends a static secret in plain text,
making webhooks susceptible to interception and replay attacks.
You can now add a signing token to any webhook. GitLab uses the signing token to compute an HMAC-SHA256 signature over:
GitLab then sends the result in the webhook-signature header alongside
webhook-id and webhook-timestamp headers, following the
Standard Webhooks specification.
You can recompute the signature to confirm requests genuinely came from GitLab and that the payload has not been modified. By also validating the timestamp, you can reject replayed requests.
Thanks to Van Anderson and Norman Debald for their community contributions!
In previous versions of GitLab, you could only use a CI/CD job token (CI_JOB_TOKEN) to push
to the same repository where the pipeline runs. Cross-project pushes required a personal access
token or deploy token.
You can now use a job token to push to another project when:
This feature is behind the allow_push_to_allowlisted_projects feature flag, disabled by default
in GitLab 19.0. Ask your administrator to enable it.
GitLab now uses Mermaid version 11 for rendering diagrams in Markdown.
Previously, GitLab supported Mermaid version 10. With this upgrade, you get access to all the new diagram types, syntax improvements, and bug fixes introduced in Mermaid 11, including enhanced rendering for flowcharts, sequence diagrams, and more.
In previous versions of GitLab, you would have to wait for the Changes tab to load all files before you could begin reviewing, which slowed down large reviews.
Now you can use Rapid Diffs to review merge requests with faster initial load, smoother scrolling, and more responsive interactions across files. Rapid Diffs uses the same technology that already powers the commits page.
Rapid Diffs is in beta. Some features from the classic diff experience aren’t yet available. You can switch back at any time.
Watch the overview video and share your experience in the feedback issue.
We’re also releasing GitLab Runner 19.0 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
job_execution spanFF_SCRIPTS_TO_STEPS feature flag implementationSignatureDoesNotMatch error when downloading S3 cacheamd64, arm64, arm, and armhf in GitLab Runner 18.9.0 and laterThe list of all changes is in the GitLab Runner CHANGELOG.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。