GitLab 19.0リリースノート

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:

• On by default
• Off by default
• Always off

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.

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:

• Merge Request Pipelines: Automatically runs a dependency scanning scan each time new commits are pushed to a branch with an open merge request. Results include only new vulnerabilities introduced by the merge request.
• Branch Pipelines (default only): Runs automatically when changes are merged or pushed to the default branch, providing a complete view of your default branch’s dependency posture.

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:

• Application information
• Cleartext authentication
• CORS
• DNS rebinding
• Framework debug mode
• Heartbleed OpenSSL vulnerability
• HTML injection
• Insecure HTTP methods
• JSON hijacking
• JSON injection
• Open redirect
• OS command injection
• Path traversal
• Sensitive file
• Sensitive information
• Session cookie
• Shellshock
• SQL injection
• TLS configuration
• Authentication token
• XML injection

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:

• The unique webhook ID.
• The request timestamp.
• The webhook payload.

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:

1. The target project opts in.
2. The user who starts the pipeline has at least the Developer role in the target project.

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.

What’s New

• Runner instrumentation: Feature negotiation, OTLP export client, and first job_execution span
• Add configurable prepare stage timeout to runner configuration

Bug Fixes

• Comprehensive fixes for FF_SCRIPTS_TO_STEPS feature flag implementation
• SignatureDoesNotMatch error when downloading S3 cache
• Runtime error when GitLab Runner runs in AWS with S3 cache
• Broken RPM S3 download links for amd64, arm64, arm, and armhf in GitLab Runner 18.9.0 and later
• Negative exit codes are reported incorrectly on Windows
• Incorrect Kubernetes executor service container naming documentation

The list of all changes is in the GitLab Runner CHANGELOG.

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.