GitLab 19.0 release notes

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. Primary features Group-level custom review instructions for GitLab Duo Tier: Premium, Ultimate Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated Add-ons: GitLab Duo Enterprise Links: Documentation · Related Issue 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. Configure work item types Tier: Premium, Ultimate Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated Links: Documentation · Related Issue 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 item displays with its 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. GitLab Secrets Manager now available in open beta Tier: Premium, Ultimate Offering: GitLab.com, GitLab Self-Managed Links: Documentation · Related Issue 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 enhancements for merge request workflows Tier: Free, Premium, Ultimate Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated Links: Documentation · Related Issue 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. Dependency scanning by using SBOM generally available Tier: Ultimate Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated Links: Documentation · Related Issue 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 trans

Excerpt shown under the publisher's RSS terms · 200 words · full text and figures are on the publisher's site