On April 16, 2026, GitLab 18.11 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
We are excited to recognize Rinku C, a Level 4 contributor with over 80 merged improvements across GitLab since joining in September 2025.
Nominated by Arianna Haradon, Senior Fullstack Engineer on the Developer Relations team, this award celebrates his sustained and meaningful impact over time. Rinku has strengthened security-sensitive flows by requiring scopes on project and group access token creation forms, and improved everyday GitLab experience with numerous updates like next/previous navigation in job logs, excluding empty searches from recent, and reducing file tree clutter through thoughtful UI refinements that make common workflows clearer and easier to navigate. Rinku tackles the work that often goes unclaimed, keeping the codebase healthy and compounding to meaningful, lasting value. Thank you for your contributions!
Agentic SAST Vulnerability Resolution is now generally available in GitLab 18.11 on the GitLab Duo Agent Platform. It runs as part of your SAST scan, after SAST false positive detection runs, or when manually triggered for individual SAST vulnerabilities.
Agentic SAST Vulnerability Resolution:
We welcome your feedback in issue 585626.
The Data Analyst Agent is a specialized AI chat assistant that helps you query, visualize, and surface data across the GitLab platform.
Backed by the GitLab Query Language (GLQL), the Data Analyst can retrieve and analyze data about each of the supported data sources, and provide clear, actionable insights about your software development health and engineering efficiency.
These insights can be visualized directly in the agent output and embedded directly into issues and epics for further evaluation.
The AI-powered CI Expert Agent is now available in beta. This agent helps teams get from GitLab code to a first working pipeline without starting from a blank .gitlab-ci.yml.
Using GitLab Duo Agent Platform, the agent inspects your repository, asks a few guided questions about your build and test process, and generates a ready-to-run pipeline you can review, edit, and commit.
This turns pipeline creation into a conversational, context-aware experience, while still letting you take full control of the YAML after you’re ready to evolve and optimize your configuration.
Default vulnerability severities don’t always reflect your organization’s actual risk. A critical CVE in an internal-only service might not warrant the same urgency as one in a public-facing application, yet teams spend significant time triaging findings that don’t match their risk model.
Vulnerability management policies can now automatically adjust the severity of vulnerabilities based on conditions like CVE ID, CWE ID, file path, and directory. When applied, the policy updates the severity of any vulnerability that matches the criteria on the default branch. Manual overrides still take precedence, and all changes are logged in the vulnerability’s history and audit events.
This reduces triage work and ensures developers focus on the findings that matter most to your business.
Teams can now create service accounts in subgroups and projects. Instead of broad, top-level group bots, you can attach a dedicated service account to a single subgroup or project and manage its access like any other member of that namespace. Group and subgroup service accounts can be invited to the group where they were created or to any descendant subgroups and projects. Project service accounts are limited to their own project.
Service accounts are now available on GitLab.com in all tiers. Previously limited to Premium and Ultimate, service accounts let you perform automated actions, access data, or run scheduled processes without tying credentials to individual team members. They’re commonly used in pipelines and third-party integrations where credentials must stay stable regardless of team changes. On GitLab Free, you can create up to 100 service accounts per top-level group, including those created in subgroups or projects.
Fine-grained personal access tokens (PATs) are now available in beta. Unlike legacy PATs, which grant access to every project and group you belong to, fine-grained PATs let you limit each token to specific resources and actions. This reduces the potential impact of a leaked or compromised token.
Your existing PATs continue to work as before, and you can still create legacy PATs without fine-grained permissions.
This beta release covers approximately 75% of the GitLab REST API. Full REST API coverage, GraphQL enforcement, and administrator policy controls are planned for the GA release.
To share feedback, see epic 18555.
The top CWE chart is now available on the new security dashboards. Identify the most common CWEs across your project or instance to identify opportunities for training, improvement, or program optimization. Users can group the dashboard data by severity and filter the dashboard by severity, project, and report type.
You can now deploy Gitaly on Kubernetes as a fully supported deployment method. This gives you greater flexibility in managing your GitLab infrastructure by using Kubernetes orchestration capabilities for scaling, high availability, and resource management. Previously, Kubernetes deployments required custom configurations and weren’t officially supported, making it difficult to maintain reliable Gitaly deployments in containerized environments.
A powerful aspect of CI/CD inputs is that you can manually run new pipelines with new values for runtime customization. This was not available in merge request (MR) pipelines before, but in this release you can now customize inputs in MR pipelines too.
After you configure inputs for MR pipelines, you can optionally modify those inputs and change the pipeline behavior any time you run a new pipeline for a merge request.
We’ve made an update to improve your Agentic Chat experience in GitLab. The default model for Agentic Chat was upgraded from Claude Haiku 4.5 to Claude Sonnet 4.6, hosted on Vertex AI. Claude Sonnet 4.6 offers improved reasoning and response quality but uses a higher GitLab Credit multiplier than Haiku 4.5.
You can select an alternative model, including Haiku, using the model selection setting. If you’ve already selected a specific model, your choice is preserved. This update only affects the default and will not override any existing selections. For information about credit multipliers by model, see the GitLab Credits documentation.
You can now configure tool options and parameter values directly in your custom flow definitions to supersede the LLM default values. This gives you more precise, consistent control over how tools behave within a custom flow, making it easier to enforce guardrails and specific parameter values across that flow.
GitLab Duo Agent Platform now supports Mistral AI as an LLM platform for self-hosted model deployments. GitLab Self-Managed customers can configure Mistral AI alongside existing supported platforms, including AWS Bedrock, Google Vertex AI, Azure OpenAI, Anthropic, and OpenAI. This gives teams more choice in how they run AI-powered features.
The GitLab Credits dashboard in Customers Portal now supports historical month navigation. Billing managers can browse past billing months to review daily usage trends, compare consumption patterns across periods, and reconcile usage with invoices. Previously, the dashboard only displayed the current billing month. With this improvement, administrators can make more informed decisions about credit allocation and forecast future needs based on historical data.
Administrators can now set a monthly usage cap for On-Demand Credits at the subscription level. When total on-demand credit consumption reaches the configured cap, GitLab Duo Agent Platform access is automatically suspended for all users on that subscription until the next billing period begins or the admin adjusts the cap. This setting gives organizations a hard guardrail against unexpected overage bills, removing a key barrier to broader Agent Platform rollout. Caps reset automatically each billing period, and administrators receive an email notification when the cap is reached.
Administrators can now set an optional per-user usage cap for GitLab Credits per billing period. When an individual user’s total credit consumption reaches the configured limit, GitLab Duo Agent Platform access is suspended only for that user, while other users continue unaffected. This prevents any single user from consuming a disproportionate share of the organization’s credit pool, and gives administrators fine-grained control over usage distribution. Per-user usage caps work alongside subscription-level usage caps, by applying the cap that is reached first.
In GitLab 19.0, the minimum-supported version of PostgreSQL will be version 17. To prepare for this change, on instances that don’t use PostgreSQL Cluster, upgrades to GitLab 18.11 will attempt to automatically upgrade PostgreSQL to version 17.
If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 17 to be able to upgrade to GitLab 19.0.
The GitLab backup Rake task for Linux package installations and the [backup-utility](https://docs.gitlab.com/charts/backup-restore/)
for Cloud Native (Helm) installations now support the container registry metadata database.
You can now back up references to blobs, manifests, tags, and other data stored in the metadata database,
enabling recovery in the event of malicious or accidental data corruption.
We’re excited to announce improvements to the groups list in Explore, making it easier to discover groups across your GitLab instance. The redesigned interface introduces a tabbed layout with two views:
These changes streamline group discovery and provide clearer visibility into which groups are available to join.
In previous versions of GitLab, transfers of large groups and projects could timeout. As we move groups and projects to use a unified state model for operations such as transfer, archive, and deletion, you get more consistent behavior, better visibility into state history and audit details, and fewer timeouts, specifically, for long running transfer operations through asynchronous processing.
For GitLab Self-Managed instances, we now have improved recommendations and configuration guidance for the GitLab ClickHouse integration. Customers have options to bring their own cluster, or use the ClickHouse Cloud (recommended) setup option. This integration powers multiple dashboards and unlocks access to various API endpoints within the analytics space.
This scalable, high-performance database is part of the larger architectural improvements planned for the GitLab analytics infrastructure.
The GitLab Duo and SDLC trends dashboard delivers improved analytics capabilities to measure the impact of GitLab Duo on software delivery. The dashboard now includes new single stat panels for monthly Agent Platform unique users and Agentic Chat sessions. Additionally, metrics previously displayed as a % usage compared to seat assignments have been updated to strictly report usage counts. This change resolves the issue where counts were missing Agent Platform usage controlled under the new usage billing model.
The GitLab Query Language (GLQL) now has access to three new data sources: projects, pipelines, and jobs. These new data sources are also available as embedded views, letting teams surface pipeline results, job statuses, and project overviews directly in wikis, issue and merge request descriptions, and repository Markdown files. GLQL also powers the Data Analyst Agent.
With these new types, the agent can inspect CI/CD job results, debug failures, and provide detailed overviews of pipeline execution, as well as provide an accurate overview of projects in a namespace.
GitLab dependency scanning using SBOM now supports generating a dependency graph automatically for Maven and Python projects. Previously, dependency scanning required users to provide a lock file or a graph file to get an accurate dependency analysis. Now, when a lock file or graph file is not available, the analyzer automatically attempts to generate one. This improvement makes it easier for Maven and Python projects to enable dependency scanning without requiring a lock file.
You can now perform incremental scans that analyze only changed parts of the codebase with GitLab Advanced SAST, significantly reducing scan times compared to full repository scans. This feature is a further iteration of diff-based scanning, because it produces full results for codebases.
By scanning just the code that has changed rather than the entire codebase, your teams can integrate security testing more seamlessly into their development workflow without sacrificing speed or adding friction.
Advanced SAST can now surface unverified vulnerabilities (findings that cannot be fully traced from source to sink) directly in the vulnerability report. Enable this feature if you have a higher tolerance for false positives over false negatives.
This feature is in beta status. Provide feedback in issue 596512.
GitLab now fully supports Kubernetes version 1.35. If you want to deploy your applications to Kubernetes and access all features, upgrade your connected clusters to the most recent version. For more information, see supported Kubernetes versions for GitLab features.
You can now set the container registry metadata database to prefer mode, a new configuration option alongside the existing true and false values. In prefer mode, the registry automatically detects whether it should use the metadata database or fall back to legacy storage based on the current state of your installation.
If your registry has existing filesystem metadata that has not been imported to the database, the registry continues to use legacy storage until you complete a metadata import. If the database is already in use, or on a fresh installation, the registry uses the database directly.
In a later release, prefer mode will become the default for new Linux package installations. Existing installations will not be affected. For more information, see issue 595480.
Teams publishing Terraform modules through the built-in GitLab Terraform module registry had
no way to restrict who could push new module versions. Package protection rules supported
several package formats but did not include terraform_module, leaving infrastructure
teams without a project-level push control.
You can now create package protection rules scoped to terraform_module, restricting push
access based on minimum role. Support is available in the UI package type dropdown, the
REST API, the GraphQL API, and the GitLab Terraform provider resource.
When creating a GitLab Release, packages published to the package registry were not automatically associated with it. Teams had to manually construct package URLs and attach them as release links through the API or pipeline scripts, adding friction and risk of incomplete release records.
GitLab now automatically includes packages in release evidence when the package version matches the release tag. This creates a verifiable, auditable link between your release and its associated packages without any manual steps, keeping source code, artifacts, and packages together in one complete release snapshot.
The wiki sidebar toggle is now positioned on the left side, directly next to the sidebar it controls.
When the sidebar is collapsed, the toggle remains visible as a floating control so you can reopen it without scrolling back to the top of the page.
The action bar on wiki pages is now sticky, so it remains visible as you scroll through a page. Previously, you had to scroll back to the top to access actions like editing, viewing page history, or managing templates. Now the page title and key actions, including Edit, New page, Templates, Page history, and more, stay within reach no matter how far down the page you are.
Epics now support weights, making it easier to estimate and prioritize large-scale initiatives during planning.
Before breaking down an epic into child issues, you can assign a preliminary weight to represent your initial estimate. As you decompose the epic, the weight automatically updates to reflect the rolled-up total from all child issues. This is consistent with how weight rollup works for issues and tasks.
On the epic detail page, you can see both the preliminary weight and the rolled-up weight from child issues, giving you the insight needed to refine estimates over time.
Previously, merge request (MR) approval policies could block MRs based on vulnerability severity, but not all vulnerabilities carry the same risk. CVSS severity alone doesn’t tell you whether a CVE is being exploited or how likely exploitation is. This leads to noisy approval policies and wasted time for developers and security teams.
You can now configure MR approval policies using Known Exploited Vulnerability (KEV) and Exploit Prediction Scoring System (EPSS) data. Block or require approval when a finding is in the KEV catalog (actively exploited in the wild), or when its EPSS score is above a threshold. Policy violations in the MR include KEV and EPSS context so developers understand why the security gate was triggered.
This gives security teams precise control over which findings block or warn, reduces alert fatigue, and keeps enforcement aligned with the current threat landscape.
CVSS 4.0 is the latest version of the industry standard used to assess and rate the severity of a vulnerability. You can now view and access CVSS 4.0 score in the UI, including the vulnerability details page and the vulnerability report. You can also query the score using the API.
Previously, you had to select the row description to navigate to a vulnerability details page from the vulnerability report.
You can now select anywhere in the row to go directly to its details. Link styling for the vulnerability description and file location only appears when you hover over each link, and keyboard navigation has been improved.
These changes make the vulnerability report more intuitive and accessible.
You can export the security dashboard as a PDF for use in reports and presentations. The export captures the current state of all of the charts and panels in the dashboard, including any active filters.
In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile. In GitLab 18.11, profiles now extend to SAST with the Static Application Security Testing (SAST) - Default profile, giving you a unified control surface to apply standardized static analysis coverage across all your projects without touching a single CI/CD configuration file.
The profile activates two scan triggers:
You can now filter the results in a group security dashboard based on the security attributes that you have applied to the projects in that group.
The available security attributes include the following:
The Security Manager role is now available as a beta feature, providing a new default set of permissions designed specifically for security professionals. Security teams no longer need Developer or Maintainer roles to access security features, eliminating over-privileging concerns while maintaining separation of duties.
Users with the Security Manager role have the following access:
To get started, go to a group and select Manage > Members to invite and assign members to the Security Manager role.
The vulnerability report now shows the primary CVE identifier as a clickable link in each row. When multiple identifiers exist,
a "+N more" popover lists all of the identifiers. Each identifier in the list links to its external reference
(for example, in the CVE, CWE, or WASC databases) so you can quickly access more details without leaving the report.
We’re also releasing GitLab Runner 18.11 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.
concrete helper image with bundled dependenciesdocker-machine binary in GitLab Runner 18.9.0 references CVE-2025-68121DOCKER_AUTH_CONFIGCONCURRENT_PROJECT_ID not unique in different jobs, which causes a conflict in the builds directoryafter_script executes after failed pre_build_script and bypasses post_build_scriptThe list of all changes is in the GitLab Runner CHANGELOG.
On March 19, 2026, GitLab 18.10 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Harshith is currently a Level 3 Contributor who has made impactful contributions improving community tooling and analytics, from triage automation and contributor recognition to GitLab Duo usage insights.
Harshith’s contributions were first recognized by Lee Tickett, Fullstack Engineer in DevRel Engineering at GitLab, who nominated him. His work has strengthened how we support contributors behind the scenes through improvements to our automation and contributor-facing experiences. For example, he expanded our triage automation by updating the IssueSummary processor in triage-ops to work with multiple projects, including contributors.gitlab.com, making it easier for us to keep more community projects consistently summarized and visible. He also helped recognize community-created content through the new “Add content” button and flow, which lets contributors log blog posts, videos, and other content directly from their profile and get rewarded.
Harshith has also contributed to our analytics and GitLab Duo usage insights. Highlights include refining how GitLab Duo usage is calculated, improving how AI impact over time can be explored by removing the 180-day default, and consolidating DORA metric date range constants, as well as enhancing analytics at scale with improvements like adding infinite scroll for the Value Stream Analytics custom stage label picker. Together, these changes help teams better understand how GitLab is used in real projects.
In his own words:
“One thing I’ve really enjoyed while contributing is how thoughtfully ideas are discussed within the community. It’s encouraging to see suggestions explored collaboratively, like in the discussion around MR !1288, which turned into a great learning experience. I’m really happy to be part of this community and look forward to making many more contributions in the future.”
Thank you, Harshith, for your ongoing work to improve the GitLab codebase and contributor experience!
Want to connect with Harshith and learn more about his contributions? Visit Harshith’s GitLab profile and his LinkedIn profile.
SAST false positive detection, which was first introduced as a beta in GitLab 18.7, is now generally available in GitLab 18.10.
When a security scan runs, GitLab Duo Agent Platform analyzes each critical and high severity SAST vulnerability and determines the likelihood that it’s a false positive. The assessment appears directly in the vulnerability report, giving teams the context they need to triage with confidence rather than uncertainty.
Key capabilities include:
This feature is available for Ultimate customers with GitLab Duo Agent Platform. The feature must be enabled in your group or project settings. We welcome your feedback in issue 583697.
Free tier group Owners on GitLab.com can now unlock AI with GitLab Credits. Purchase a monthly credit amount, commit to an annual term, and get access to GitLab Duo Agent Platform agents and flows. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.
Key highlights:
This purchase option is currently only available for free GitLab.com top-level groups.
GitLab now supports passkeys for passwordless sign-in and as a phishing-resistant two-factor authentication (2FA) method. Passkeys use public-key cryptography and biometric authentication (fingerprint, face recognition) or your device PIN to securely access your account.
Passkeys offer the following benefits:
To get started, add a passkey in your account settings. We welcome your questions and feedback in issue 366758.
The GitLab planning experience is getting a significant upgrade with the work items list and saved views, bringing together two long-requested capabilities:
This is the next step in the GitLab work items journey, a unified architecture designed to deliver consistency and unlock new capabilities across GitLab planning tools.
Share your thoughts and feedback in issue 590689.
You can now connect custom agents in the AI Catalog to external data sources and tools through the Model Context Protocol (MCP), without leaving GitLab.
This feature is an experiment. Share your feedback in issue 593219.
Maintaining consistent merge request titles is important for teams that rely on structured naming conventions. Whether that’s following the Conventional Commits format, or linking to an internal tracking system. Teams previously needed external tooling or custom CI/CD pipeline jobs to enforce these conventions, but this approach had a critical gap. If someone changed the merge request title after the pipeline ran, there was no re-validation, and the MR could still be merged with a non-compliant title.
You can now configure a required title regex for merge requests in your project settings. When configured, GitLab evaluates the merge request title against the pattern as a mergeability check — blocking the merge until the title is updated to comply, regardless of when the title was last changed.
To set this up, go to your project’s Settings > Merge requests and enter a regex pattern in the Merge request title must match regex field.
Your existing merge request workflows continue to work as before. This check only applies to projects where you explicitly configure a title regex.
Security teams spend significant time investigating secret detection findings that turn out to be false positives. For example, test credentials, example values, and placeholder tokens that are incorrectly flagged as actual secrets. False positives create alert fatigue, erode trust in scan results, and divert attention from genuine security risks.
GitLab 18.10 introduces AI-powered secret false positive detection (beta) to focus on the secrets that actually matter. When a security scan runs, GitLab Duo automatically analyzes each Critical and High severity secret detection vulnerability to determine if it’s a false positive.
The AI assessment appears directly in the vulnerability report, giving security engineers immediate context to make faster and confident triage decisions.
Key capabilities include:
This feature is available as a free beta for Ultimate customers and must be enabled in your group or project settings. Share feedback in issue 592861.
Using CI/CD variables for dynamic job configuration can be challenging. Variables follow a complex override hierarchy that’s difficult to manage, and they can’t be used for a variety of use cases.
Now you can use inputs to define explicit, typed inputs at the job level. Use job inputs to define and control the values that a job accepts at runtime. With job inputs, you get:
Job inputs can use the default values without any user interaction, but you can modify the values when retrying a job or running a manual job.
The [gitlab_blob_search](../../user/duo_agent_platform/agents/tools.md) tool now enables GitLab AI agents to search your code:
Previously, blob search was limited to a single project, or required specifying explicit project IDs. This change makes it easier for AI-powered workflows to discover and reuse code that’s spread across multiple related projects.
You can now manage your CI/CD pipelines in a GitLab project with the new manage_pipeline tool.
This GitLab MCP server tool lets AI agents create, cancel, retry, delete, and update pipeline metadata in a single call.
With this tool, you no longer have to piece together multiple steps to automate your pipeline workflows.
If you want to see other GitLab MCP sever tools, let us know in the feedback issue.
Previously, enabling AI agents and flows from the AI Catalog required top-level group permissions.
Now, when browsing the AI Catalog at the explore level or project level, project Maintainers can enable agents and flows directly in their projects.
You can now configure network access controls for flows using GitLab runners in projects.
This provides secure external integrations, while maintaining control over network destinations. This also gives project maintainers the flexibility to allow necessary API connections, MCP servers, and third-party services while enforcing security boundaries.
Configure network access controls in the network_policy section of agent-config.yml. The agent-config.yml is protected by branch protection rules and MR approval workflows.
Vertex AI is now a supported LLM platform within GitLab Duo Agent Platform Self-Hosted.
Customers can now configure Anthropic models hosted on Vertex AI for use with GitLab Duo Agent Platform features.
Maintainers and Owners can now enable agents and flows directly from their project or the explore page, without navigating away from their current context.
Top-level group Owners can also select their group, and the specific projects where they want to activate agents and flows, streamlining their workflow setup.
GitLab Duo Agent Platform now supports the Agent Skills specification, an emerging standard for giving AI agents new capabilities and expertise.
You can define Agent Skills at the workspace level for your project to give agents specialized knowledge and workflows for specific tasks, like writing tests in a specific framework. Agents automatically discover and load relevant skills as they encounter matching tasks.
You can also trigger skills manually by name, file path, or custom slash commands. Agent Skills are accessible for flows and Agentic Chat in your IDE, and for flows run in CI/CD pipelines. They also work with any other AI tool that supports the specification.
Billing managers can now download credit usage data as a CSV file directly from the GitLab Credits dashboard in Customers Portal.
The export provides a daily, per-action breakdown of credit consumption for the current billing month, including commitment, waiver, trial, on-demand, and included credits used.
Finance and operations teams can use this data to perform cost allocation, chargeback reporting, and usage analysis in Excel, Google Sheets, or BI tools without manual data gathering or support requests.
The GitLab Credits dashboard now links credit consumption directly to the GitLab Duo Agent Platform session that generated it.
In the per-user drill-down view, the Action column for Agent Platform usage rows (such as Agentic Chat or Foundational Agents) is now a clickable hyperlink that navigates to the corresponding session details.
This link provides a direct audit trail from billing to AI session behavior, so administrators can investigate credit usage, support escalations, and compliance reviews without manually correlating timestamps across separate systems.
Enterprise administrators can now sort the Usage by User table in the GitLab Credits dashboard by total credits used or by username.
The default sort order is by total credits consumed (highest first), so the top consumers are immediately visible without scrolling.
With this view, administrators managing thousands of GitLab Duo users can quickly identify high-usage individuals for cost allocation, chargeback reporting, and license utilization audits.
We’ve streamlined the projects page in Explore to reduce clutter and remove redundant options that accumulated over time. The simplified interface now focuses on two core views:
We’ve removed several redundant tabs:
The cleaner design aligns with other project lists for visual consistency. You can still access all the same content through more logical organization and flexible sorting options.
GitLab dependency scanning by using SBOM now supports scanning Java build.gradle and build.gradle.kts build files.
Previously, dependency scanning for Java projects using Gradle required a lock file to be present.
Now, when a lock file is not available, the analyzer automatically falls back to scanning build.gradle and build.gradle.kts files, extracting and reporting only direct dependencies for vulnerability analysis.
This improvement makes it easier for Java projects using Gradle to enable dependency scanning without requiring a lock file.
To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".
In GitLab 18.10, we’re extending limited availability status to self-managed instances for the new SBOM-based dependency scanning feature.
This feature was initially released in GitLab 18.5 with limited availability for GitLab.com only, behind the feature flag dependency_scanning_sbom_scan_api and disabled by default.
With additional improvements and fixes, we now have confidence to reliably use the new SBOM scanning internal API and enable this feature flag by default. This internal API allows the dependency scanning analyzer to generate a dependency scanning report containing all component vulnerabilities. Unlike the previous behavior (Beta) that processed SBOM reports after CI/CD pipeline completion, this improved process generates scan results immediately during the CI/CD job, giving users instant access to vulnerability data for custom workflows.
Self-managed customers who encounter issues can disable the dependency_scanning_sbom_scan_api feature flag. The analyzer will then fall back to the previous behavior.
To use this feature, import the v2 dependency scanning template Jobs/Dependency-Scanning.v2.gitlab-ci.yml.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, please reach out in this feedback issue.
GitLab now supports license scanning for Dart and Flutter projects that use the pub package manager.
Previously, teams building with Dart or Flutter were unable to identify the licenses of their open source dependencies directly within GitLab, creating compliance blind spots for organizations with license policy requirements.
License data is sourced directly from pub.dev, the official Dart package repository, and results are surfaced alongside other supported ecosystems. Dart/Flutter dependency scanning and vulnerability detection were already supported.
C and C++ development teams using Conan as their package manager have long requested registry support in GitLab. Previously, the Conan package registry was experimental and only supported Conan 1.x clients, limiting adoption for teams that have migrated to the modern Conan 2.0 toolchain.
The Conan package registry now supports Conan 2.0 and has been promoted from Experimental to Beta. This release includes full v2 API compatibility, recipe revision support, improved search capabilities, and proper handling of upload policies including the --force flag. Teams can publish and install Conan 2.0 packages directly from GitLab using standard Conan client workflows, reducing the need for external artifact management solutions like JFrog Artifactory.
With this update, platform engineering teams managing C and C++ dependencies can consolidate their package management within GitLab alongside their source code, CI/CD pipelines, and security scanning. The Conan registry supports both project-level and instance-level endpoints, and works with personal access tokens, deploy tokens, and CI/CD job tokens for authentication.
We welcome feedback as we work toward general availability. Please share your experience in the epic.
When the container virtual registry launched in beta last milestone, platform engineers could aggregate multiple upstream container registries — Docker Hub, Harbor, Quay, and others — behind a single pull endpoint. However, all configuration required direct API calls, meaning teams had to maintain scripts or manual curl commands to create and manage their registries, configure upstreams, and handle changes over time. This added operational overhead and made the feature inaccessible to users who weren’t comfortable working directly with the API.
Container virtual registries can now be created and managed directly from the GitLab UI. From the group-level container registry page, you can create new virtual registries, configure upstream sources with authentication credentials, edit existing configurations, and delete registries you no longer need — all without leaving GitLab or writing a single API call. The UI integrates seamlessly with the existing container registry experience, making virtual registries a first-class part of your group’s artifact management workflow.
This feature is in beta. To share feedback, please comment in the feedback issue.
Teams using Helm to manage Kubernetes application deployments can now rely on the GitLab Helm Chart registry for production workloads. Previously in beta, the registry is now generally available following the resolution of key architectural and reliability concerns.
The path to GA included resolving a hard limit that prevented the index.yaml endpoint from returning more than 1,000 charts, fixing a background indexing bug that caused newly published chart versions to be missing from the index, completing a full AppSec security review, and adding Geo replication support for Helm metadata cache, ensuring high availability for self-managed customers running GitLab Geo.
Platform and DevOps teams can publish and install Helm charts directly from GitLab using standard Helm client workflows, with support for project-level endpoints and authentication using personal access tokens, deploy tokens, and CI/CD job tokens. Now you can keep charts alongside the source code, pipelines, and security scanning that depend on them.
You can now use task item checkbox syntax directly in Markdown table cells.
Previously, achieving this required a combination of raw HTML and Markdown, which was cumbersome and difficult to maintain.
This improvement makes it easier to track task completion directly within structured table layouts in issues, epics, and other content.
In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile, starting with push protection. You use the profile to apply standardized secret scanning across hundreds of projects without touching a single CI/CD configuration file.
The Secret Detection - Default profile now also covers pipeline-based scanning, providing a unified control surface for secret detection across your entire development workflow.
The profile activates three scan triggers:
Applying the profile requires no YAML configuration. The profile can be applied to a group to propagate coverage across all projects in the group, or to individual projects for more granular control.
You can now create, test, and deploy applications for the newest generations of Apple devices using macOS Tahoe 26 and Xcode 26.
With hosted runners on macOS, your development teams can build and deploy macOS applications faster in a secure, on-demand build environment integrated with GitLab CI/CD.
Try it out today by using the macos-26-xcode-26 image in your .gitlab-ci.yml file.
We’re also releasing GitLab Runner 18.10 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.
gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2 results in init-permissions errorThe list of all changes is in the GitLab Runner CHANGELOG.
On February 19, 2026, GitLab 18.9 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Pooja has made significant contributions to ongoing efforts at GitLab to migrate legacy dropdown components to our modern dropdown architecture. These migrations require careful attention to detail and an understanding of both the old and new component systems. Pooja has consistently delivered high-quality work across multiple migrations, including updates to the diff file header, code block bubble menu, oncall schedules rotation assignee component, and the new resource dropdown.
Peter Hegman, Staff Frontend Engineer on Tenant Scale::Organizations at GitLab, nominated Pooja for this recognition, noting: “These migrations can be pretty tricky and she has completed a number of them. Thanks for your contributions!”
Beyond these migration efforts, Pooja has also contributed to feature development, including adding statuses to milestones and iterations, a feature she put significant effort into getting merged. Marc Saleiko, Staff Fullstack Engineer on Plan:Project Management at GitLab, recognised her work: “This is a valuable contribution and you did a great job delivering this functionality!” Reflecting on her experience, Pooja shared: “I’m proud of how it turned out and it was a great learning experience for me.”
She has also contributed numerous bug fixes and maintenance improvements across the GitLab codebase. Pooja’s work directly improves the maintainability and consistency of the GitLab user interface, making it easier for both contributors and team members to build and maintain features, and helping move the GitLab frontend architecture forward.
Thank you, Pooja, for your continued contributions to improving the GitLab codebase and for being such a reliable member of our contributor community!
Want to learn more about Pooja’s contributions? Check out her GitLab profile.
GitLab Duo Agent Platform is now generally available for GitLab Self-Managed customers with a cloud license. Billing for this feature is usage-based.
Administrators can configure compatible models for use with GitLab Duo Agent Platform. Administrators using AWS Bedrock or Azure OpenAI can also configure Anthropic Claude or OpenAI GPT models.
Not yet on Ultimate? Start a free trial with Duo Agent Platform included.
Triaging and remediating SAST vulnerabilities is one of the most time-consuming tasks in application security. After identifying a real vulnerability, developers need to understand the finding, locate the affected code, and write an appropriate fix. All of which take time and specialized knowledge. In GitLab 18.9, we’re introducing Agentic SAST Vulnerability Resolution. When you trigger resolution for a SAST vulnerability, GitLab Duo autonomously analyzes the finding, reasons through the surrounding code context, generates a context-aware fix, and creates a merge request without any manual intervention.
Key capabilities include:
SAST vulnerability resolution is available from the vulnerability report and the individual vulnerability details pages. You can trigger a resolution directly from the individual vulnerability details page.
This feature is available as a free beta for Ultimate customers. We welcome your feedback in issue 585626.
You can now browse repository files with a collapsible file tree. The tree provides a comprehensive view of your project structure, so you can expand and collapse directories inline, jump between files in different parts of your repository, and maintain context while you work.
The file tree appears as a resizable sidebar when you view repository files or directories. You can toggle visibility with keyboard shortcuts, filter files by name or extension, and navigate through complex project hierarchies. The tree synchronizes with your current location, so when you select a file in the main content area, the tree updates to show that file.
Your existing repository structure and file organization remain unchanged. With fewer page loads required to move between files, this feature scales from small projects to large codebases with thousands of files.
Previously, pipeline inputs could only be defined directly within a pipeline’s spec section. This limitation made it challenging to reuse input configuration across multiple projects.
In this release you can now include input definitions from external files using the familiar include keyword. Being able to maintain a list of inputs in a separate place helps you have a manageable solution across many projects or pipelines. You can maintain centralized input configurations and even dynamically manage input values from external sources.
Ensuring commits are cryptographically signed is essential for code integrity and meeting compliance requirements. Previously, web-based commit signing was only available for GitLab Self-Managed.
GitLab.com now supports web-based commit signing. When enabled for a group or project, commits created through the GitLab web interface are automatically signed with the GitLab signing key and are displayed with a Verified badge, providing cryptographic proof of authenticity for your repositories.
Key details:
This brings the GitLab.com security capabilities in line with GitLab Self-Managed and provides the foundation for comprehensive commit signing policies across your organization.
Modern container-based development requires accessing images from multiple registries including Docker Hub, Harbor, Quay, and private registries. Without a container virtual registry, platform engineers must configure each project and CI/CD pipeline to authenticate with and pull from multiple registries individually. This creates configuration complexity, slows pulls with sequential registry queries, and makes it difficult to implement consistent security policies across container sources.
The container virtual registry addresses these challenges by aggregating multiple upstream container registries behind a single endpoint. Platform engineers can configure Docker Hub, Harbor, Quay, and other registries with long-lived token authentication through one URL. Intelligent caching improves pull performance while integrating with the GitLab authentication systems for centralized access control and audit logging.
The container virtual registry API is currently available in beta for GitLab Premium and Ultimate customers. Beta participants can use the GitLab API to create container virtual registries, configure multiple upstream sources with shareable configurations, and pull container images through the virtual registry. Please note the beta does not support registries that require IAM authentication. Support for cloud provider registries requiring IAM authentication is tracked in this epic.
On GitLab.com, this feature is behind a feature flag. To request access or share feedback, please comment in the feedback issue.
The new Vulnerabilities by age chart helps you understand how long vulnerabilities have been open in your environment.
The chart shows the distribution of unresolved vulnerabilities based on the amount of time since they were first detected. You can group vulnerabilities by severity or by report type, helping you identify where remediation activities may be needed.
The GitLab Duo plugin for JetBrains IDEs now supports OAuth authentication for GitLab Self-Managed and GitLab Dedicated. This means all JetBrains users can now enjoy a faster, more secure sign-in experience. No personal access token required.
Previously, organizations that used identity providers to automate user provisioning on GitLab Self-Managed Premium might run into a potential problem. When identity provider syncs attempt to add users beyond the licensed seat limit, administrators must either purchase extra seats for users who don’t need active access, or manually intervene to prevent failures.
Now, users with the Minimal Access role on GitLab Self-Managed Premium subscriptions no longer count as billable seats, bringing them in line with how minimal access works on GitLab.com Premium, GitLab.com Ultimate, and GitLab Self-Managed Ultimate. This change unlocks the restricted access feature, which automatically assigns the Minimal Access role to users who would otherwise exceed the seat limit during identity provider syncs. This change keeps syncs running smoothly without unexpected billing overages or manual intervention.
You can now troubleshoot and verify data integrity directly from the primary site, thanks to the new data management view that brings detailed verification status information to the primary Geo site. This enhancement eliminates the need to access secondary sites for basic verification and troubleshooting tasks.
Previously, this verification status was only accessible through the secondary site UI. Now, with the data management view on the primary site, you can:
This enhancement is the first step toward comprehensive self-serve troubleshooting with the UI, reducing the need to access multiple sites for routine maintenance and issue resolution.
Teams evaluating GitLab can now test agentic AI capabilities that automate complex development workflows and reduce manual tasks. Sign up for a GitLab Ultimate trial and get access to Duo Agent Platform with 24 evaluation credits per user, enabling hands-on experience with autonomous task execution and multi-step workflow orchestration during a 30-day evaluation. Evaluation credits are available for 30 days from the provision date, so consider your team’s readiness before starting.
Start your free trial. Current paid customers can access evaluation credits through their account team. Contact Sales to learn more.
Zero Downtime Upgrades are now officially supported for Cloud Native Hybrid deployments.
Enterprise customers require their DevSecOps platform to be available at all times, making upgrade-related downtime a significant operational concern. Until now, Zero Downtime Upgrades were only supported for Linux package-based high availability deployments, which drove many customers toward VM-based architectures even when cloud-native Kubernetes deployments would have better suited their infrastructure strategy.
We’ve been upgrading our own Cloud Native Hybrid SaaS instances with zero downtime for years. With this release, we’re bringing that same operational experience to self-managed customers running GitLab on Kubernetes.
The upgrade procedure has been comprehensively tested and is now fully documented, giving you the confidence to maintain availability during version upgrades.
Managing completed initiatives and abandoned projects is now easier. You can now archive entire groups, including all subgroups and projects, in one action, eliminating the need to manually archive each project individually.
When you archive a group:
Beyond the Settings page, you can archive groups and projects directly from the actions menu in list views. No more navigating through multiple screens for simple administrative tasks. This highly requested feature dramatically reduces administrative overhead while keeping your workspace organized with clear separation between active and inactive work. Share your feedback in epic 18616.
Starting with GitLab 18.9, Valkey is bundled as an opt-in replacement for Redis in the Linux package. Redis changed their license to AGPLv3, which is not suitable for open source customers. To guarantee security and maintainability for our GitLab Self-Managed customers, we are transitioning from Redis to Valkey, a community-driven fork that maintains the permissive BSD license.
Transition timeline:
This transition only affects the bundled Redis in Linux packages. Customers on scaled architectures using external Redis deployments can continue to use Redis. We are monitoring the potential feature divergence between Redis and Valkey and will provide guidance as the ecosystem evolves.
GitLab dependency scanning by using SBOM now supports scanning Java pom.xml manifest files.
Previously, dependency scanning for Java projects using Maven required a graph file to be present.
Now, when a graph file is not available, the analyzer automatically falls back to scanning pom.xml files, extracting and reporting only direct dependencies for vulnerability analysis.
This improvement makes it easier for Java projects to enable dependency scanning without requiring a graph file.
To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".
GitLab dependency scanning by using SBOM now supports scanning Python requirements.txt manifest files.
Previously, dependency scanning for Python projects required a lock file to be present.
Now, when a lock file is not available, the analyzer automatically falls back to scanning requirements.txt files, extracting and reporting only direct dependencies for vulnerability analysis.
This improvement makes it easier for Python projects to enable dependency scanning without requiring a lock file.
To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".
Organizations using GitLab.com need to ensure that enterprise users don’t accidentally expose sensitive code through personal snippets. Previously, there was no way to prevent users from creating snippets in their personal namespace, which can pose a security risk if snippets are inadvertently set to public.
Group Owners can now restrict personal snippet creation for enterprise users, helping maintain tighter control over where code is shared. When restricted, enterprise users cannot create snippets in their personal namespace.
Reviewing commits with many changed files or substantial modifications can be slow.
Rapid Diffs technology now powers the commits page (/-/commits/<SHA>), delivering faster
loading times, smoother scrolling, and more responsive interactions.
With Rapid Diffs, you’ll notice:
All existing functionality is preserved. As Rapid Diffs expands to other areas of GitLab, the same performance benefits will follow.
The GitLab import API now supports Bitbucket Cloud API tokens, providing a more secure way to import repositories from Bitbucket Cloud.
Atlassian has deprecated app passwords in favor of API tokens, and we’re planning to remove support for app passwords in 19.0.
Importing from Bitbucket Cloud through the GitLab UI is not affected by this change.
Manage and visualize security scanner coverage across your organization. This release introduces security configuration profiles, starting with the secret detection profile. Security teams now have a more powerful command center to secure your organization at scale.
Profile-based security configuration
Instead of manually editing YAML files for each project, you can now use preconfigured security configuration profiles that provide several advantages:
The secret detection profile is the first security configuration profile available. It provides the following advantages:
Enhanced security inventory
The security inventory has been upgraded to act as your primary dashboard to assess each group’s security posture:
Security attributes, introduced as a beta in GitLab 18.6, are now generally available.
Security attributes allow security teams to apply business context to their projects, including business impact, application, business unit, internet exposure, and location. You can also create custom attribute categories to match your organization’s taxonomy. By applying these attributes, you can filter and prioritize the items in your security inventory based on risk posture and organizational context.
The Vulnerabilities over time chart is updated to provide a more accurate view of your vulnerability inventory.
The chart previously included vulnerabilities that were no longer detected, leading to inflated numbers that did not accurately represent the state of active vulnerabilities.
We are aware of two additional issues that may slightly alter counts in some cases. Follow issue 590022 and issue 590018 for updates.
GitLab CI/CD analytics now combines CI/CD pipeline and CI/CD job performance trends, which enables developers to identify inefficient or problematic CI/CD jobs quickly. These capabilities are included directly in the GitLab UI, so developers have the tools they need in context to identify and fix CI/CD performance problems that can significantly impact development teams’ velocity and overall productivity. For platform administrators, the CI/CD jobs data in this view also reduces the need to rely on external or custom-built CI/CD observability solutions when you operate GitLab at an enterprise scale.
You can now view timestamps on each CI job log line to identify performance bottlenecks and debug long-running jobs. Timestamps are displayed in UTC format. Use timestamps to troubleshoot performance issues, identify bottlenecks, and measure the duration of specific build steps. Requires GitLab Runner 18.7 or later for GitLab Self-Managed.
Previously, teams lacked visibility into how CI/CD Catalog component projects were being used across their organization. Now you can view usage counts and adoption patterns at a high level, helping you understand which component projects are most valuable and optimize your catalog investments.
You can now view security and compliance reports from child pipelines directly in merge request widgets. Previously, you had to manually navigate through multiple pipelines to identify security issues, creating inefficient workflows especially with monorepos and complex testing setups.
With this enhancement, the merge request widget displays reports from child pipelines directly alongside parent pipeline results, with each child pipeline’s reports presented individually and artifacts available for download. This provides a unified view of all security checks, significantly reducing time spent investigating failures and enables faster merge request reviews when using parent-child pipelines.
On January 15, 2026, GitLab 18.8 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
This month’s Notable Contributor is Wesley Yarde for building a foundational new feature that allows organizations to disable SSH keys for their enterprise users.
Wesley’s contribution stands out for several reasons:
The implementation spanned multiple merge requests (!205020, !210482) with thorough review cycles. Despite the complexity, Wesley demonstrated outstanding collaboration and patience throughout the process.
“It was a pleasure to collaborate with Wesley on this feature request! While both the contributor and reviewers may have felt that the review process was overwhelming, both sides showed understanding and superb collaboration to ensure the implementation is solid and complete.” — Bogdan Denkovych, who nominated Wesley for this recognition.
Congratulations Wesley, and thank you for this valuable contribution to GitLab!
GitLab Duo Agent Platform is now generally available, bringing agentic AI orchestration across your entire software development lifecycle. Unlike AI tools that speed up individual tasks in isolation, the Agent Platform helps teams coordinate AI agents across planning, building, securing, and shipping software, closing the gap between faster individual work and the collaborative, multi-stage reality of software delivery.
The platform provides a central AI Catalog where teams can discover, manage, and share agents and flows across their organization. Built-in foundational agents like Planner, Security Analyst, and Data Analyst handle structured work at key decision points, while customizable flows automate multi-step agents and tasks in development workflows from issue to merge request, CI/CD migration, pipeline troubleshooting, and code reviews.
With governance controls, usage visibility, and flexible deployment options including self-hosted models for offline environments, organizations can adopt AI at scale with the transparency and control they need.
GitLab Premium and Ultimate users can start using the Agent Platform today on GitLab.com and GitLab Self-Managed instances with promotional GitLab Credits.
The Planner Agent is now generally available! The Planner Agent is a foundational agent built to support product managers directly in GitLab.
Use the Planner Agent to create, edit, and analyze GitLab work items. Instead of manually chasing updates, prioritizing work, or summarizing planning data, the Planner Agent helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It’s like having a proactive teammate who understands your planning workflow and works with you to make better, more efficient decisions.
Please provide your feedback in issue 583008.
The GitLab Duo Security Analyst Agent, introduced as beta in GitLab 18.5, is now generally available in GitLab 18.8.
The Security Analyst Agent enables engineers to manage vulnerabilities through natural language commands in GitLab Duo Agentic Chat. Instead of manually clicking through vulnerability dashboards or writing custom scripts for bulk operations, security teams can now triage, assess, and provide guidance for vulnerabilities in Chat conversations.
As a foundational agent, the Security Analyst Agent is available by default in GitLab Duo Agentic Chat, with no manual setup required.
Security teams can now automatically dismiss vulnerabilities that don’t apply to their organization using vulnerability management policies. Dismissing vulnerabilities that are not relevant to your organization reduces noise and helps developers focus on vulnerabilities that pose actual risk.
You can create policies to auto-dismiss vulnerabilities based on:
Auto-dismissed vulnerabilities appear in the merge request’s security widget with an Auto-dismissed label and are tracked in the vulnerability report activity with a dismissal reason for audit purposes.
You can now turn on or off the GitLab Duo Agent Platform, including GitLab Duo Chat (Agentic), agents, and flows for a top-level group or the entire instance. When this setting is turned off, these features are not available.
You can now define group access rules to control who can use GitLab Duo features, enabling flexible adoption strategies from immediate organization-wide access to phased rollouts.
This feature provides granular governance control so you can scale adoption at your pace while maintaining security and compliance.
GitLab Duo Agent Platform is now generally available for Duo Self-Hosted. This feature is available to GitLab Self-Managed customers with an offline license, and uses seat-based pricing.
Self-Managed administrators can configure compatible models for use with GitLab Duo Agent Platform. Administrators using AWS Bedrock or Azure OpenAI can also configure Anthropic Claude or OpenAI GPT models.
Cross-file, cross-function scanning support for C/C++ is now generally available in GitLab Advanced SAST.
In GitLab 18.8, we released multi-container scanning in Beta.
Users are now able to pass in an array of images to be scanned as part of many Container Scanning jobs.
The Credentials Inventory API is now available for Enterprise users on GitLab.com. This adds credential management capabilities previously only available on self-hosted instances, and enables organizations to better manage and secure their authentication tokens and keys.
The Credentials Inventory API provides programmatic access to view credentials across your organization, including:
This API complements the existing Credentials Inventory UI, allowing enterprise administrators to automate credential management tasks that previously required manual intervention. With the Credentials Inventory API, you can:
Group Owners can now disable SSH keys for all enterprise users in their group. When disabled, users cannot add new SSH keys and their existing keys are deactivated. This applies to all enterprise users in the group, including those with the Owner role.
Thank you to Wesley Yarde for helping build this feature!
We’re also releasing GitLab Runner 18.8 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.
WaitForServicesTimeout no longer supports -1 to disable timeoutinsteadOf rulesThe list of all changes is in the GitLab Runner CHANGELOG.
On December 18, 2025, GitLab 18.7 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
We’re excited to recognize David Aniebo as our 18.7 Notable Contributor for his impactful contributions to GitLab product planning capabilities and the contributor platform.
David’s work on improving work item list functionality demonstrates his technical expertise and dedication to enhancing the user experience for GitLab planning features. This contribution helps teams better organize and manage their work items, making project planning more efficient for thousands of GitLab users.
Beyond code contributions, David has been a consistent supporter of the contributor platform, helping to improve the experience for community contributors. His collaborative approach and responsiveness have earned praise from multiple team members across different groups.
“David has done some fantastic work helping out with some Product Planning group efforts, and we are very thankful for his contributions,” shared Nick Brandt, Engineering Manager for Product Planning.
Thank you, David, for your valuable contributions to GitLab and for being such a collaborative member of our community! We look forward to your continued involvement.
When a valid secret is leaked in one of your repositories, you must react quickly. To help you prioritize urgent threats, validity checks automatically verify whether leaked credentials can still be used.
In GitLab 18.7, we’ve improved:
In this release, validity checks are generally available.
Separate models can now be selected for Agentic Chat and for all other agents for top-level groups or instances. This provides more options for model selection for GitLab Duo Agent Platform.
The GitLab Duo and SDLC trends dashboard delivers improved analytics capabilities to measure the impact of GitLab Duo on software delivery. The dashboard now provides 6-month trend analysis across GitLab Duo feature adoption, pipeline performance, and common development metrics such as deployment frequency and mean time to merge.
You can now track code generation volumes and IDE or language trends for GitLab Duo Code Suggestions, and observe as your teams adopt new GitLab Duo Agent Platform flows. Enhanced user-level metrics enable teams to gain deeper insight into the key Duo features providing continuous value.
A new endpoint for instance-level AI usage is now available for instance administrators to extract all Duo data from either Postgres (3-month retention) or ClickHouse.
Powered by the ClickHouse integration, this dashboard delivers sub-second query performance across millions of data points. For self-managed instances, see improved recommendations and configuration guidance for ClickHouse integration.
The Planner Agent now includes create and edit features in beta! The Planner Agent is a foundational agent built to support product managers directly in GitLab. Use the Planner Agent to create, edit, and analyze GitLab work items.
Instead of manually chasing updates, prioritizing work, or summarizing planning data, the Planner Agent helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It’s like having a proactive teammate who understands your planning workflow and works with you to make better, more efficient decisions.
Please provide your feedback in issue 576622.
You can set up your CI/CD pipelines to make use of dynamic input selection when creating new pipelines through the intuitive web interface.
Now, with dynamic input options, you can configure your pipelines so that input selection options update dynamically based on previous selections. For example, when you select an input in one dropdown list, it automatically populates a list of related input options in a second dropdown list.
With CI/CD inputs, you can:
This dynamic capability enables you to create more intelligent, context-aware input configurations that guide you through the pipeline creation process, reducing errors and ensuring only valid combinations of inputs are selected.
Security teams often spend significant time investigating SAST findings that turn out to be false positives, diverting attention from genuine security risks.
In GitLab 18.7, we’re introducing AI-powered SAST False Positive Detection to help teams focus on the vulnerabilities that matter. When a security scan runs, GitLab Duo automatically analyzes each Critical and High severity SAST vulnerability to determine the likelihood that it’s a false positive.
The AI assessment appears directly in the vulnerability report, giving security engineers immediate context to make faster, more confident triage decisions.
Key capabilities include:
This feature is available as a free beta for Ultimate customers and must be enabled in your group or project settings. We welcome your feedback in issue 583697.
The new security dashboards have been updated and modernized. The dashboards were previously available on GitLab.com, and are now enabled by default on GitLab Dedicated and GitLab Self-Managed.
The new features include:
Please note that using the new dashboard requires Elasticsearch.
Administrators of GitLab Self-Managed and GitLab Dedicated can now restrict which projects are allowed to publish components to the CI/CD Catalog. This new setting enables organizations to maintain a curated, trusted CI/CD Catalog by controlling what components can be published.
Administrators can now specify an allowlist of projects authorized to publish components. When the allowlist is populated with projects, only those projects can publish components. This prevents unauthorized or unapproved components from cluttering the list of published components and ensures all components meet organizational standards and security requirements.
This addresses a key governance challenge for enterprise customers who want to maintain control over their CI/CD component ecosystem while enabling their teams to discover and reuse approved components.
Advanced search now returns matching results from both merge request descriptions and comments. Previously, users had to search merge request descriptions and comments separately.
This improvement provides a more streamlined and comprehensive search workflow for GitLab merge requests.
AGENTS.md with GitLab Duo Chat (Agentic) in IDEsGitLab Duo Chat now supports the AGENTS.md specification, an emerging standard for providing context and
instructions to AI coding assistants.
Unlike custom rules that are only available to GitLab Duo, AGENTS.md files are also available for other AI
coding tools to use. This makes your build commands, testing instructions, code style guidelines, and
project-specific context available to any AI tool that supports the specification.
GitLab Duo Chat in your IDE automatically applies available instructions from AGENTS.md files in your repository,
set at the user or workspace level. For monorepos, you can place AGENTS.md files in subdirectories to provide
tailored instructions for different components.
When you enable an agent or flow from the AI Catalog in your project, GitLab now pins it to a specific version.
This means your AI-powered workflows stay stable and predictable even as catalog items evolve, so you can test and validate new versions before you upgrade.
For GitLab Duo Self-Hosted, you can now configure a timeout value for requests to self-hosted models.
This value can range from 60 to 600 seconds.
You can now report agents and flows to instance administrators when you encounter problematic content. Submit an abuse report that includes your feedback, and an administrator can choose to hide or delete the harmful item.
Use this feature to keep your agents and flows safe across your entire organization.
You can now control which foundational agents are available in your top-level group or instance.
Turn all foundational agents on or off by default, or toggle individual agents to align with your organization’s security and governance policies.
GitLab Self-Managed users on an Ultimate trial can now access their active trial status, remaining days, accessible features, and expiration notifications from the left sidebar.
These enhancements help eliminate confusion about trial duration and make it easier to evaluate paid features before purchase.
Advanced vulnerability management is available to all Ultimate customers and includes the following features:
The Data Analyst Agent is a specialized AI assistant that helps you query, visualize, and surface data across the GitLab platform. It uses GitLab Query Language (GLQL) to retrieve and analyze data, then provides clear, actionable insights about your projects.
You can find example prompts and use cases in the documentation.
This agent is currently in beta status, so please share your thoughts in the feedback issue to help us improve and provide insight into where you’d like to see this go next.
The compliance violations report provides a centralized view of all compliance violations across your organization’s projects. The report displays comprehensive details about control violations, related audit events, and enables teams to track violation statuses effectively.
In GitLab 18.7, we’ve introduced powerful filtering capabilities to help you quickly find the violations that matter most. You can now filter by:
Teams can now also collaborate directly on resolving violations through comments. Within the violation record itself, teams can:
Together, these features evolve the compliance violations report into a dynamic collaboration platform, enabling organizations to efficiently discover, analyze, and resolve compliance violations in their groups and projects.
GitLab compliance controls can be used in compliance frameworks. Controls are checks against the configuration or behavior of projects that are assigned to a compliance framework.
Previously, controls related to scanners (for example, checking if SAST is enabled) required your projects to have a passing pipeline in the default branch before the compliance centre displayed the success or failure status of your controls.
In GitLab 18.7, we have changed this behavior to show whether your controls have succeeded or failed based solely on scan completion, regardless of the overall pipeline status. This helps ease confusion because the compliance status of your controls reflects whether security scans ran and completed, not whether the entire pipeline passed.
Heading anchor links now announce with the same text as their corresponding heading, improving the experience for screen reader users. The links also appear after the heading text, providing a cleaner visual presentation.
These changes make it easier for all users to understand and navigate to specific sections of documentation, issues, and other content.
Security teams can now use warn mode to test and validate the impact of security policies before applying enforcement or to roll out soft gates for accelerating your security program. Warn mode helps to reduce developer friction during security policy rollouts, while continuing to ensure detected vulnerabilities are addressed.
When you create or edit a
merge request approval policy,
you can now choose between warn or enforce enforcement options.
Policies in warn mode generate informative bot comments without blocking merge requests. Optional approvers can be designated as points of contact for policy questions. This approach enables security teams to assess policy impact and build developer trust through transparent, gradual policy adoption.
Clear indicators in merge requests tell users when policies are in warn or enforce mode, and audit events
track policy violations and dismissals for compliance reporting. Developers can bypass scan finding and license
policy violations by providing a reasoning for the policy dismissal, creating a collaborative feedback loop between
developers and security teams for more effective policy enablement.
When policy violations are detected on a project’s default branch, policies identify vulnerabilities that violate the policy in the vulnerability reports for projects and groups. The dependency list for projects also displays badges that indicate license compliance policy violations.
Additionally, you can use the API to query a filtered list of policy violations on the default branch in a project.
Service accounts are now available during trial periods, allowing you to test automation and integration workflows before purchasing.
We’re also releasing GitLab Runner 18.7 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.
builds_dir is specifiedThe list of all changes is in the GitLab Runner CHANGELOG.
Teams using parent-child CI/CD pipelines previously had to navigate through multiple pipeline pages to check test results, code quality reports, and infrastructure changes, disrupting their merge request review workflow.
You can now view and download all reports in a unified view, including unit tests, code quality checks, Terraform plans, and custom metrics, without leaving the merge request.
This eliminates context switching and accelerates merge request velocity, giving teams the ability to deliver features faster without compromising quality.
On November 20, 2025, GitLab 18.6 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Every developer using the GitLab Development Kit (GDK) benefits from Samaksh’s
contribution to improve the readability of gdk status.
While this enhancement may appear simple on the surface, it demonstrates exceptional attention to
developer experience and understanding of how small improvements can have
widespread impact.
The improved readability of gdk status
saves time for every developer using GDK and considerably increases the
accessibility of one of the core pieces of the development environment. This
type of contribution shows maturity in understanding how to make meaningful
improvements to the developer workflow.
Reflecting on his contributions, Samaksh shares: “GitLab Development Kit (or GDK) has been my choice of active contributions for now, because I personally like to work on the side that makes experience for other contributors easy and convenient. And that’s the kind of developer I wanna be. The one that can use his skills to make others’ lives easier.”
When asked about his experience contributing to GitLab, Samaksh notes: “I’d like to recommend GitLab to everyone who wants to try a fresh and quality open source experience. When I first started contributing to GitLab, I was a bit overwhelmed but everyone in the community was so supportive, helpful and welcoming that it all went away. I am absolutely in love with the community and how they do things around here. From writing excellent documentation, to maintaining peak code quality, to genuinely appreciating their contributors, GitLab community is absolutely wonderful.”
Introducing a smarter, more intuitive GitLab UI that puts developer productivity first.
The new side-by-side design uses contextual panels to keep you in your workflow, reducing unnecessary clicks and helping teams work faster. Customize your workspace, maximize screen real estate, and enjoy a cleaner, more dynamic experience that adapts to your workflow.
GitLab is committed to continuous improvement, so please share your thoughts in the feedback issue and help shape the future of GitLab.
With this release, exact code search is now in limited availability. You can use exact match and regular expression modes to search for code across an entire instance, in a group, or in a project. Exact code search is built on top of the open-source search engine Zoekt.
For GitLab.com, exact code search is enabled by default. For GitLab Self-Managed, an administrator must install Zoekt and enable exact code search.
This feature is in active development. We welcome your feedback in issue 420920!
Previously, CI/CD components couldn’t reference their own metadata, such as version numbers or commit SHAs, within their configuration. This lack of information could cause you to use configuration with hardcoded values or complex workarounds. Writing configuration this way can lead to version mismatches when components build resources such as Docker images, because there’s no way to automatically tag those resources with the component’s compatible version.
In this release, we’ve introduced the ability to access component context with the spec:component keyword.
You can now build and publish versioned resources like Docker images when you release a component version,
ensuring everything is in sync, eliminating manual version management, and preventing version mismatches.
needs:[parallel:matrix](../../ci/yaml.md#parallelmatrix)parallel:matrix makes it possible
to easily run multiple jobs in parallel with different requirements, for example
to test code for multiple platforms at the same time. But if you wanted later jobs
to use needs:parallel:matrix to depend on specific parallel jobs, the configuration was complex
and inflexible.
Now, with the new $[[matrix.VARIABLE]] expression introduced as a Beta feature,
users can create dynamic 1-1 dependencies which makes complex parallel:matrix configurations
much easier to manage. This can help you create faster pipelines, with efficient artifact handling,
better scalability, and cleaner configuration. This feature is particularly valuable for multi-platform builds,
Terraform deployments across multiple environments, and any workflow requiring parallel processing across multiple dimensions.
The GitLab Security Analyst Agent is now a foundational agent in GitLab Duo Agentic Chat. This means that users do not have to manually add the GitLab Security Analyst agent from the AI Catalog, and this agent is available by default for GitLab Self-Managed and GitLab Dedicated as well. This specialized assistant provides AI-native vulnerability management and security analysis, helping you investigate findings, triage vulnerabilities, and navigate compliance requirements without any setup.
This feature is in beta, and we welcome your feedback in issue 576916.
Easily choose your preferred AI model right in GitLab Duo Chat, now available in the VS Code and JetBrains IDEs. Use the dropdown list in the GitLab Duo Chat panel to select among Claude, GPT, and other supported models. Model availability is managed by your organization admins, ensuring you have access to the right models for your workflow.
The new security dashboards have been updated and modernized. The initial features in the beta release include:
The new security dashboards released in 18.6 are currently available on GitLab.com only.
The GitLab MCP server is available in beta. With the GitLab MCP server, you can use AI assistants like Claude Code, Cursor, and other MCP-compatible tools to interact with your GitLab projects, issues, merge requests, and pipelines, all without building custom integrations for each tool.
To get started, turn on beta and experimental features in your GitLab Duo settings.
The GitLab MCP server provides key tools covering issues, merge requests, and pipelines, and we continue to refine it based on user feedback. This feature might have incomplete functionality or bugs. Try it out and share feedback in issue 561564.
Advanced search now returns matching results from both issue descriptions and comments. Previously, users had to search issue descriptions and comments separately. This improvement provides a more streamlined and comprehensive search workflow for GitLab issues.
You can now use the Gemini 2.5 Flash model on GitLab Duo Agent Platform with GitLab Duo Self-Hosted.
We’ve introduced rate limiting for the /api/v4/projects/:id/members/all and /api/v4/groups/:id/members/all
endpoints to improve API stability and ensure fair resource usage across all users.
The GET /api/v4/projects/:id/members/all and GET /api/v4/groups/:id/members/all
endpoints now have a rate limit of 200 requests per minute per user.
This change helps protect GitLab instances from excessive API usage that could impact performance for all users. The limit of 200 requests per minute provides ample capacity for normal usage patterns while preventing potential abuse or unintentional resource exhaustion. If your integrations or scripts use this endpoint, ensure they handle rate limit responses appropriately (HTTP 429) and implement retry logic with backoff as needed. Most users should not be affected by this change under normal usage patterns.
We’ve added support for 40 new rules to GitLab’s pipeline secret detection. Some existing rules have also been updated to improve quality and reduce false positives. These changes are released in version 7.20.1 of the secrets analyzer.
Code ownership is critical for maintaining code quality and ensuring the right
people review changes to sensitive parts of your codebase. However, managing
Code Owners in organizations with complex group structures has been challenging.
Previously, to reference a group in your CODEOWNERS file, that group had to be
directly invited to each specific project, even if it was already a member of
a parent group.
Code Owners now supports groups with inherited memberships as eligible approvers:
CODEOWNERS files continue to work without changes.This change reduces administrative overhead while maintaining the security and approval requirements that Code Owners provide.
On your homepage, draft merge requests can clutter your merge request view and distract from work that’s ready for action. Previously, you could not filter them out.
You can now hide draft merge requests from the Your merge requests section on your homepage by using the display preferences. When you hide draft merge requests:
This change helps you focus on merge requests that need immediate attention.
The GitLab CLI (glab) provides new features and improvements to enhance your GitLab workflow from the command line:
ci-view command.For a full list of changes and updates, see CLI releases. To get started with the GitLab CLI or update to the latest version, see the installation guide.
Webhook integrations are critical for automating workflows and keeping external systems synchronized with GitLab merge request activities. However, when reviewers were re-requested for merge requests, webhook consumers had no way to identify which specific reviewer was being re-requested, making it difficult to trigger appropriate notifications or automation.
Webhook payloads for merge requests now include a re_requested attribute
in reviewer data that clearly indicates which reviewer was re-requested:
true for the specific reviewer being re-requested.false for all other reviewers.This improvement enables more precise automation around the merge request review process. Webhook consumers can send targeted notifications, update external tracking systems, and trigger appropriate workflows when reviews are re-requested.
GitLab Self-Managed administrators in offline or tightly controlled network environments can now configure a custom Web IDE extension host domain, enabling full Web IDE functionality without external internet access.
Previously, the Web IDE required connectivity to .cdn.web-ide.gitlab-static.net to load VS Code extensions and functionality. This requirement blocked Web IDE adoption for security-conscious organizations, government and public sector customers, and enterprises with strict network policies.
With this update, administrators can configure their GitLab instance to serve Web IDE assets directly, removing the dependency on external domains. You can now:
Integrating GitLab with external systems through webhooks is critical for automated workflows and keeping teams informed about merge request status changes. However, when GitLab automatically resets approvals (such as when new commits are pushed to a merge request with “Reset approvals on push” enabled), external systems could not distinguish these system-initiated events from manual user actions.
GitLab now includes enhanced webhook payloads that clearly identify system-initiated approval resets. When approvals are automatically reset, webhooks now include:
system field set to true.system_action field that provides specific context about why the reset occurred, such as approvals_reset_on_push or code_owner_approvals_reset_on_push.This means your webhook integrations can now distinguish between manual approval changes and automatic system resets, enabling more sophisticated automation workflows that respond appropriately to the specific context of each approval change.
The GitLab Duo Planner Agent is now available by default in the agent dropdown in GitLab Duo Chat, eliminating the need to manually add it from the AI Catalog. With full context of your work items, epics, issues, and tasks, the Planner Agent can now assist you at both the group and project levels.
Get started with [example prompts](../../user/duo_agent_platform/agents/foundational_agents/planner.md#example-prompts) to see how the Planner Agent can help you break down complex work, create implementation plans, and organize your team’s objectives.
This feature is in beta, and we welcome your feedback in issue 576622.
GitLab’s Helm chart registry previously generated metadata responses on-the-fly, which created performance bottlenecks when repositories contained large numbers of charts. To maintain system stability, we enforced a hard limit of the 1,000 most recent charts. This limit caused frustrating 404 errors when platform teams tried to access older chart versions.
Platform engineers were forced to implement complex workarounds, like splitting charts across multiple repositories, manually managing chart retention policies, or maintaining separate chart storage solutions. These workarounds added operational overhead and fragmented deployment workflows, making it harder to maintain centralized chart governance.
In GitLab 18.6, we’ve eliminated the 1,000 chart limitation by pre-computing metadata responses and storing them in object storage. This architectural change delivers both unlimited chart access and improved performance, as metadata is generated once in background jobs rather than on every request.
Security teams can now use warn mode to test and validate the impact of security policies before applying enforcement, reducing developer friction during security policy rollouts.
When you create or edit a merge request approval policy, you can now choose between warn or enforce enforcement options.
Policies in warn mode generate informative bot comments without blocking merge requests. Optional approvers can be designated as points of contact for policy questions. This approach enables security teams to assess policy impact and build developer trust through transparent, gradual policy adoption.
Clear indicators in merge requests tell users when policies are in warn or enforce mode, and audit events track policy violations and dismissals for compliance reporting. Developers can dismiss vulnerabilities while providing reasoning for the dismissal, creating a collaborative approach to security policy management.
Security teams can now apply business context to projects by leveraging security attributes.
Security attributes are organized by categories including business impact (with structured pre-defined selections), application, business unit, internet exposure, and location. Alternatively, you can create your own attribute categories and define labels within those categories.
By applying these attributes across your projects, you can much more quickly search, filter, and identify which projects within the security inventory that require action based on risk posture and organizational context. You may now:
Organizations can now designate specific users, groups, roles, or custom roles that can bypass merge request approval policies in case critical situations occur. This capability provides flexibility for emergency responses, while maintaining comprehensive audit trails and governance controls.
Emergency bypass with accountability: Designated users can bypass approval requirements during critical incidents, security hotfixes, or urgent production issues. When emergencies strike, authorized personnel can merge or push changes immediately while the system captures detailed justification and audit information for compliance review.
Key capabilities include:
security_policy.bypass_reason.This feature eliminates the need to entirely disable security policies during emergencies, providing a controlled path for urgent changes while preserving organizational governance and audit requirements.
You can now designate an account beneficiary permission to manage your GitLab account if you are incapacitated or unavailable. To access your account, the beneficiary must provide appropriate legal documentation. This feature helps ensure the continuity of your work and projects while preventing unauthorized access.
Group owners can can now update the primary email address of enterprise users in their group. Updates can be made through the Users API. Previously, each enterprise user had to manually update their own email address. This change makes it easier to manage enterprise users at scale.
We’re also releasing GitLab Runner 18.6 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On October 16, 2025, GitLab 18.5 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
In his blog post “How GitLab Can Boost Your Professional Career”, Jose shares: “For me, the main advantage that GitLab offers, from a professional development point of view, is that it is open source.” He adds, “For GitLab, it’s important that anyone can contribute, and for that reason, they have taken the contributor onboarding process very seriously.”
Jose’s journey from first-time contributor in September to Notable Contributor in October demonstrates the power of the GitLab collaborative community. Through active participation in community office hours, Discord discussions, and pairing sessions, Jose found a supportive environment that helped him quickly grow to a level 3 contributor with diverse contributions spanning documentation, code, and community support.
The GitLab community offers a welcoming space where contributors support one another and grow together. Whether you’re just starting your open-source journey or looking to deepen your skills, our community is here to help you succeed.
To learn more about contributing, see the GitLab Contributor Platform.
Thank you, Jose, for your outstanding work! 🚀
Collaborate with GitLab Duo Planner, a GitLab Duo agent built to support product managers directly within GitLab. Instead of manually chasing updates, prioritizing work, or summarizing planning data, GitLab Duo Planner helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It’s like having a proactive teammate who understands your planning workflow and works with you to make better, faster decisions. This feature is currently in beta. Please provide feedback in issue 576622.
Agents in GitLab Duo Agent Platform can be used to perform tasks and answer complex questions within GitLab. Users can either create custom agents to accomplish specific tasks, like creating merge requests or reviewing code, or discover GitLab agents using the AI Catalog.
In GitLab 18.5, we are releasing the GitLab Security Analyst Agent as a beta feature, available in the AI Catalog. To use the GitLab Security Analyst Agent in specific projects, select and enable the agent in GitLab Duo Agentic Chat. The agent can perform the following tasks:
detected.With the GitLab Security Analyst Agent, users can perform tedious security workflows through AI-powered automation and intelligent analysis, enabling engineers to focus on genuine threats while the GitLab Security Analyst Agent handles repetitive assessment and documentation. Please note that the GitLab Security Analyst Agent using GitLab Duo Chat is only available for Ultimate customers with the GitLab Duo add-on.
This feature is in beta, and we welcome your feedback in issue 576916.
GitLab 18.5 introduces a comprehensive web-based interface for Maven virtual registry management. Previously, platform engineers could only configure and manage virtual registries through API calls, which makes routine maintenance tasks cumbersome and requires specialized knowledge.
This web-based approach significantly reduces operational overhead for platform engineering teams. Common tasks, like clearing stale cache entries, reordering upstreams for performance optimization, and testing connectivity are now point-and-click operations. Development teams gain better visibility into their dependency configuration, enabling more informed discussions about build performance and security policies.
The Maven virtual registry remains in beta for GitLab Premium and Ultimate customers. Current beta limitations include a maximum of 20 virtual registries per top-level group and 20 upstreams per virtual registry.
We invite enterprise customers to participate in the Maven virtual registry beta program to help shape the final release. Please consider sharing feedback and suggestions in issue 543045.
You can now access a new personal homepage that consolidates all your important GitLab activities in one place, making it easier to pick up where you left off. The homepage brings together your to-do items, assigned issues, merge requests, review requests, and recently viewed content, helping you navigate GitLab’s large surface area and stay focused on what matters the most to you.
OpenAI GPT-5 is now available as a GitLab AI Vendor model when selecting a model for GitLab Duo Agent Platform. When configured by Owners of a top-level group on GitLab.com and instance Administrators on Self-Managed and Dedicated, end-users can select to use GPT-5 with GitLab Duo features. Top-level owners and administrators can continue to set organization-wide model preferences through namespace or instance settings, or allow end-user to choose from all available GitLab AI Vendor models.
To get started using GPT-5, select your preferred model from the model dropdown list in GitLab Duo Chat.
Enterprise users want to manage their compliance frameworks and security policies across multiple top-level groups. This is often the case when all groups in an instance:
With GitLab 18.5, we introduce compliance and security policy groups to centralize the management of security policies and compliance frameworks on an instance for GitLab Self-Managed and Dedicated instances. With this release, you can now create, configure, and allocate compliance frameworks and security policies from a single top-level group and enforce them across all of the other top-level groups across your instance.
With a compliance and security policy group, you have a single source of truth where you can manage and edit your compliance frameworks and security policies. Security and compliance users within the group can then apply compliance frameworks and security policies to all the projects across the instance.
Compliance and security policy groups make it easier to manage and enforce your compliance and security needs across your instance. However, groups still retain the ability to create their own compliance frameworks and security policies to address specific situations or workflows that can arise in those groups.
This feature is for GitLab Self-Managed and Dedicated customers. GitLab.com customers can manage frameworks and policies centrally within a single top-level group or namespace using security policy projects.
Learn more about compliance and security policy groups for compliance frameworks and security policies.
You can now add scripts to your CI/CD configurations to automate DAST authentication workflows. Authentication scripts enable automating complex authentication flows, including support for time-based, one-time passwords (OTP MFA).
This enhancement helps your team maintain critical security controls while conducting thorough, automated security scans. By supporting real-world authentication scenarios, scripts reduce friction and ensure accurate security assessments of production software.
You can now trigger CLI agents using additional events to give you more flexibility and control over where and when your agents take action across your projects. Along with the existing mention trigger, you can use:
GitLab Duo Agent Platform is now in beta for GitLab Duo Self-Hosted. This feature is available to all Self-Managed GitLab Duo Enterprise customers. Self-Managed instance administrators using AWS Bedrock or Azure OpenAI can configure Anthropic Claude or OpenAI GPT models for use with GitLab Duo Agent Platform. Self-Hosted administrators can also configure
to use with GitLab Duo Agent Platform.
You can now use Mistral Codestral on
GitLab Duo Self-Hosted
for classic Duo Chat. This model is supported for GitLab Duo Self-Hosted customers on GitLab Self-Managed instances.
You can now use GPT OSS models on GitLab Duo Agent Platform with GitLab Duo Self-Hosted.
We’ve upgraded the Admin area groups list to provide a more consistent experience for GitLab administrators:
This update brings the administrator experience in line with GitLab design standards, and adds important safety features to protect your data. Future enhancements to group management will automatically appear in all group lists throughout the platform.
We’ve made changes to the group overview list to deliver a more consistent and efficient experience across GitLab. These improvements make it easier to navigate your groups and projects while providing more valuable information at a glance:
These enhancements save time by putting more information and actions at your fingertips. This update also lays the groundwork for future features like bulk editing and advanced filtering options.
The Inactive tab now consistently displays all inactive items in one unified location across GitLab. This includes archived projects, projects pending deletion, and groups pending deletion.
This tab is available on the group overview page, as well as in group and project lists throughout Your work, Explore, and the Admin area.
All users with the appropriate permissions can view inactive items, while only group owners and project owners and maintainers can take further actions on them.
As part of this update, a new active parameter is now available in both the Projects and Groups REST APIs, and GraphQL APIs.
Managing inactive content is a critical part of maintaining a GitLab instance. This update makes it easier to find and recover content that was archived or is pending deletion, allowing you to maintain better control over your GitLab resources while reducing the risk of accidentally losing valuable work. The clear separation of active from inactive content also provides a more focused search experience when navigating through groups and projects across all areas of GitLab.
GitLab Duo Agentic Chat is an enhanced version of GitLab Duo Chat. It searches, retrieves, and combines information from multiple sources across your GitLab projects to provide more thorough and relevant answers. A few of its use cases include the ability to search through projects, read and list files, and autonomously create and change files based on the prompt provided to GitLab Duo Chat.
In GitLab 18.5, the Agentic Chat use case expands to include managing vulnerabilities from your security scanners. By adding vulnerability management tools to Agentic Chat, this transforms tedious security workflows through AI-powered automation and intelligent analysis, enabling security professionals to efficiently triage, manage, and remediate vulnerabilities through natural language commands. This eliminates hours of manual clicking through vulnerability dashboards and streamlining complex bulk operations that previously required custom scripts or tedious manual work.
With the new vulnerability management tools added to GitLab Duo Chat, Ultimate users with GitLab Duo can perform the following:
detected.These tools transform security workflows from reactive manual triage into intelligent remediation, letting engineers focus on genuine threats while AI handles repetitive assessment and documentation. Vulnerability management using GitLab Duo Chat is only available for Ultimate customers with the GitLab Duo add-on.
We have added beta support for C/C++ to GitLab Advanced SAST.
To use this new cross-file, cross-function scanning support, enable C/C++ support.
We welcome feedback on this feature. If you have any questions, comments, or would like to engage with our team, please see this feedback issue.
Pipeline secret detection alerts you to exposed credentials, like passwords or API keys, in your projects. However, until GitLab 18.5, you had to manually check whether each detection represented an active token. This could make effectively triaging detections difficult and time consuming.
Now that validity checks is in beta, enable it to display the status of detected GitLab secrets. Active secrets can be used to impersonate legitimate activity, so you should rotate them as soon as possible. To watch validity checks in action, see the validity checks playlist.
New rules have been added to the GitLab pipeline secret detection. Some existing rules have also been updated to improve quality and reduce false positives. These changes are released in version 7.15.0 of the secrets analyzer.
You can now create custom security detection rules tailored to your organization’s specific security requirements and coding patterns with GitLab Advanced SAST. This feature enables your security teams to define custom vulnerability patterns beyond the predefined ruleset, allowing them to detect application-specific security issues.
For more information, see Customize rulesets.
You can now perform diff-based scans that analyze only the code changes in a merge request with GitLab Advanced SAST, significantly reducing scan times compared to full repository scans. By scanning just the Git diff rather than the entire codebase, your teams can integrate security testing more seamlessly into their development workflow without sacrificing speed or adding friction to the merge request process.
We are working to enable this performance improvement by default; this is tracked in issue 546359.
External controls can be attached to requirements when creating compliance frameworks in GitLab.
By default, GitLab automatically requests the status of external controls from external systems every 12 hours during compliance scans, setting the control status to ‘pending’. External systems then respond by using the external controls API to update the status to ‘pass’ or ‘fail’.
In GitLab 18.5, you can now disable this automatic 12-hour ping by turning off the Ping enabled setting when configuring external controls. When the 12-hour ping is disabled:
This prevents the system from resetting the external control statuses to ‘pending’ and gives you full control over status update timing.
In GitLab 18.5, we released a new dependency scanning template that works with the dependency scanning analyzer. The analyzer now generates a dependency scanning report containing all component vulnerabilities. Scan Execution Policy (SEP) and Pipeline Execution Policy (PEP) support the new template.
To use the new template, import Jobs/Dependency-Scanning.v2.gitlab-ci.yml.
This feature is available on GitLab.com and self-managed instances, though it’s marked as limited availability because official support for self-managed is not yet available. GitLab.com users can use it immediately.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, please see this feedback issue.
deployment_tierYou can now use CI/CD variables in the environment:deployment_tier field, making it easier to
dynamically configure deployment tiers based on pipeline conditions.
Previously, issues and tasks were required to share the same set of configured statuses. In this release, we’ve added support for configuring status lifecycles, enabling you to define distinct workflows for issues and tasks in your projects. With status mapping built into the workflow, you can seamlessly transition an issue or task to a new set of statuses with no bulk editing required when changing work item types.
Share your feedback and help us improve the feature by contributing to our feedback issue with your use cases and suggestions.
Misaligned Markdown tables are difficult to read and edit, even though they render correctly.
The new Reformat table feature in the plain text editor’s toolbar realigns table columns with a single click, preserving alignment settings and indentation. To use it:
This makes documentation maintenance faster and collaboration easier when working with complex tables.
You can now track the progress of issues directly from the child items widget, giving you a status overview at a glance. This enhancement provides real-time visibility into potential bottlenecks when work is already in progress, helping you quickly identify at-risk items and make timely adjustments before sprint deadlines are threatened.
The vulnerabilities GraphQL API now exposes the original severity of vulnerabilities. This allows you to determine what the severity of the vulnerability was before severity overrides were applied.
To provide further flexibility in security vulnerability comparisons, we have introduced time windows in merge request approval policies. If the security reports for the most recent baseline are not yet available, this new policy configuration allows you to use previously completed security reports, as long as the reports are not older than the age that you specify as the time window.
Development teams can now avoid unnecessary delays when baseline security scans are stuck or taking too long, such as in very busy projects. By configuring a time window, merge requests that don’t introduce new vulnerabilities can proceed without waiting for the latest pipeline to complete, improving workflow efficiency.
To use this feature, create or edit a merge request approval policy and specify the security_report_time_window parameter (in minutes) in your approval policy configuration
The system will compare your merge request’s security results against the latest pipeline using the security reports created within the specified time window, allowing for faster approvals when no new vulnerabilities are introduced.
Previously, in the Security tab for a pipeline, if you dismissed an vulnerability, the vulnerability was not immediately removed from the list.
Status updates in the security tab of a pipeline page are now updated after they are changed.
Organizations can now designate specific users, groups, roles, or custom roles that can bypass merge request approval policies in case critical situations occur. This capability provides flexibility for emergency responses, while maintaining comprehensive audit trails and governance controls.
Emergency bypass with accountability: Designated users can bypass approval requirements during critical incidents, security hotfixes, or urgent production issues. When emergencies strike, authorized personnel can merge or push changes immediately while the system captures detailed justification and audit information for compliance review.
Key capabilities include:
security_policy.bypass_reason.This feature eliminates the need to entirely disable security policies during emergencies, providing a controlled path for urgent changes while preserving organizational governance and audit requirements.
Previously, the dependency list included some dismissed vulnerabilities.
To provide you with a more useful representation of the vulnerabilities in the dependency list, the project dependency list now includes only active vulnerabilities in the detected and confirmed states.
In GitLab 18.5, we released limited availability support for static reachability. This release focuses on improving JS/TS coverage support, fixing bugs, and providing experimental support for Java. Static reachability enriches Software Composition Analysis (SCA) results by scanning project source code to identify open source dependencies that are in use. Data produced by static reachability can be used as part of users’ triage and remediation decision making. Static reachability data can also be used with CVSS and EPSS scores, as well as KEV indicators to provide a more focused view of identified vulnerabilities.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, please see this feedback issue.
We’re also releasing GitLab Runner 18.5 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.
Bug fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
On September 18, 2025, GitLab 18.4 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Patrick Rice continues his exceptional dedication to GitLab’s open source community as contributor, maintainer, and mentor. A top 5 contributor over the past year, Patrick maintains the GitLab Terraform Provider and client-go projects, handling feature additions, releases, issue triage, and community onboarding. He embodies GitLab’s mission that everyone can contribute, having worked his way up from contributor to project maintainer.
Patrick’s impact extends beyond code contributions to community building and coaching, helping new contributors get started and grow in the project. Patrick previously nominated and supported Heidi Berry who won the 17.11 Notable Contributor award. He also shared insights with the GitLab for Education team on working with students learning GitLab to help us grow the next generation of developers.
“I’d love to encourage new contributors to join us in collaborating on the Terraform Provider and client-go projects,” Patrick says. “We can always use more friendly faces in our community.”
“Patrick has continued relentlessly supporting the GitLab team and customers,” says Lee Tickett, Staff Fullstack Engineer at GitLab, who nominated Patrick for the award. Timo Furrer, Senior Backend Engineer at GitLab, supported the nomination. “Apart from his daily contributions to the Terraform Provider and client-go,” Timo adds, “he’s helping GitLab customers directly with their IaC journey by showcasing what is possible with the GitLab Terraform Provider.”
Patrick is an Enterprise Architect at Kingland and member of the GitLab Community Core Team. This marks his second Notable Contributor award, having previously won in GitLab 15.8 in January 2023.
Thanks to Patrick for his sustained contributions and dedication to supporting GitLab customers and growing our open source community!
GitLab Duo Model Selection is now generally available, giving organizations greater control over which AI models power their development workflows.
Owners of top-level groups on GitLab.com and administrators on Self-Managed and Dedicated can now choose a specific model from a variety of GitLab AI model vendors for use with their GitLab Duo features, accessed through the GitLab-hosted AI gateway.
GitLab users that belong to multiple namespaces on GitLab.com can now also set a default namespace to ensure consistent AI model preferences across all development contexts. For more information on GitLab Duo Model Selection, read the blog.
The GitLab Knowledge Graph provides rich code intelligence across your codebase. Developers can understand and navigate their projects with greater context, making it easier to plan changes, perform impact analysis, and work with GitLab Duo agents to accelerate development tasks.
The GitLab Duo Agent Platform leverages the Knowledge Graph to increase the accuracy of AI agents. By mapping files and definitions across a codebase, the Knowledge Graph provides enhanced context that allows Duo agents to understand relationships across your entire local workspace—unlocking faster and more precise responses to complex questions.
This release of the Knowledge Graph focuses on local code indexing, where the CLI turns your codebase into a live, embeddable graph database for RAG. You can install it with a simple one-line script, parse local repositories, and connect via MCP to query your workspace.
Our vision for the Knowledge Graph project is two-fold: building a vibrant community edition that developers can run locally today, which will serve as the foundation for a future, fully integrated Knowledge Graph Service within GitLab.com and self-managed instances.
This feature is in beta status. Provide feedback in issue 160.
GitLab Duo model selection for end-users is now in public beta on GitLab.com. Users can now select their preferred model for GitLab Duo Agentic Chat directly in the GitLab UI, giving developers personalized control over their AI assistance experience.
When allowed by namespace owners on GitLab.com, end-users can choose from available GitLab AI Vendor models for use with GitLab Duo Agentic Chat. Namespace owners can continue to set organization-wide model preferences through namespace settings, or allow end-user model selection.
To get started, look for the model dropdown in GitLab Duo Agentic Chat to select your preferred model. Note that changing models will start a fresh conversation, and your preferences will be remembered for future sessions.
You can now allow CI/CD job tokens generated in your project to authenticate Git push requests to the project’s repository.
Enable this with the Job token permissions settings in the UI, or alternatively with the [ci_push_repository_for_job_token_allowed](../../api/projects.md#edit-a-project)
parameter in the project’s REST API endpoint.
GitLab Duo context exclusion allows you to control which project content is excluded as context for GitLab Duo. This is helpful to protect sensitive information such as password files and configuration files. You can exclude individual files, specific directories, specific file types, or any combination of these.
This feature is currently in beta. Provide feedback on GitLab Duo context exclusion in issue 566244.
GitLab Dedicated now supports deployment in all AWS regions, enabling you to select from an expanded list of regions for your primary, secondary, and backup deployment location.
This expansion is enabled by AWS’s rollout of io2 disks across all regions, which meet GitLab Dedicated’s standards for high availability and disaster recovery.
All newly available regions can be selected when provisioning your GitLab Dedicated instance in Switchboard.
Previously, when using the pipeline editor and validating your changes using the Validate tab, you could only run a simulation for the default branch. In this release, we’ve expanded this capability. You can now select any branch to simulate pipelines against. This improvement gives you greater flexibility in testing and validating your pipelines. You can ensure they perform as expected across different cases, including your stable branches or feature branches.
You can now use group or application settings to enable automatic Duo Code Review for multiple projects. This can help you quickly enable Duo Code Review for all projects in a group, rather than individually enabling specific projects.
This feature is currently available in GitLab.com, and we plan to make it available for GitLab Self-Managed in a future release. Provide feedback in issue 517386.
GitLab Self-Managed customers with GitLab Duo Enterprise can now use additional supported models with GitLab Duo. OpenAI GPT-5 is now supported on Azure OpenAI. Open source OpenAI GPT OSS 20B and 120B aer also now supported on vLLM and Azure OpenAI. To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.
GitLab Duo Code Review on GitLab Duo Self-Hosted is now generally available. Use Code Review on GitLab Duo Self-Hosted to accelerate your development process without compromising on data sovereignty. When Code Review reviews your merge requests, it identifies potential bugs and suggests improvements for you to apply directly. Use Code Review to iterate on and improve your changes before you ask a human to review. This feature includes support for Mistral, Meta Llama, Anthropic Claude, and OpenAI GPT model families.
Provide feedback on Code Review in issue 517386.
Pipeline secret detection now automatically excludes certain file types and directories if they have a low likelihood of containing secrets, improving scan performance. These changes are released in analyzer version 7.11.0.
Version 7.12.0 of the secret detection analyzer adds significant improvements to the way Git commits are fetched. The analyzer now parses --depth and --since options passed from SECRET_DETECTION_LOG_OPTIONS, so you can further specify how many commits you want to scan. The analyzer also selects appropriate fetch strategies based on context, which prevents a known issue where potentially millions of commits were unnecessarily fetched, even with shallow depth configurations.
This enhancement reduces job timeouts, decreases resource consumption, and provides more predictable scan performance. Experience faster secret detection scans, especially in large repositories, with clearer logging that matches the actual fetching behavior.
Every minute counts when you’re enabling security scans in your merge requests and pipelines. We routinely ship performance improvements for Advanced SAST, targeting both the engine and its detection rules.
In this release, we’re highlighting a specific improvement that cuts scan runtime by as much as 78% in our benchmark and real-world tests. We’ve added caching in a performance-sensitive part of the scanning process, leading to significantly faster scans in large repositories.
This improvement is automatically enabled in Advanced SAST analyzer version 2.9.6 and later. You can see which analyzer version you’re using by checking scan job logs.
You can now configure Operational Container Scanning (OCS) to only return vulnerabilties at or above a certain severity level. After you set a severity threshold, vulnerabilities below the severity you choose are no longer returned in the Vulnerability Report, API payloads, and other reporting mechanisms. This can help you focus on the vulnerabilities you want to remediate.
To enable this filtering, set a severity_threshold in your OCS configuration.
We gratefully acknowledge this community contribution from John Walsh. To learn more about contributing to GitLab, check out the Community Contribution program.
The GitLab container registry now supports the media types to host OpenTofu modules and providers.
Version 3.1.0 of the
OpenTofu CI/CD component supports
a new provider-release template to deploy an OpenTofu provider into the GitLab registry
using the OCI format. Now, you can host private OpenTofu providers directly in GitLab.
In addition, the module-release template now supports a new type input that you can set to oci
to deploy the OpenTofu module in the GitLab registry using the OCI format.
Users with the Owner role for a group can now bypass user confirmation when reassigning placeholders to active enterprise users in that group. This way, enterprise users do not have to keep checking their emails to confirm reassignments. After the time limit for the setting is reached, email confirmation requests are sent again for all new reassignments.
Enterprise users still receive notification emails after the reassignment is complete, ensuring transparency throughout the process.
You now have full control over your listing page view, choose which metadata appears and whether to open work items in a drawer, making it easier to focus on the information that matters most to you.
Previously, all metadata fields were always visible, which could make scanning through work items overwhelming. Now you can customize your view by turning on or off specific fields like assignees, labels, dates, and milestones.
With the new toggle that switches between the drawer view and full-page navigation you can quickly review details while maintaining context of your list, or open the full page when you need more screen space for detailed editing and comprehensive navigation.
We’ve replaced the “epic” filter on the Issues and Epics pages with a more flexible “parent” filter. This change lets you filter by any parent work item, not just epics. You can now easily find child tasks by filtering by their parent issue, or find issues by filtering by their parent epic, giving you better visibility into your work hierarchy across both issue and epic lists.
You can now view all issues from child epics when filtering by a parent epic in issue boards, bringing consistency with how the Issues page already works. This improvement helps you better track and visualize your complete epic hierarchy without missing any issues nested in child epics, making your project management workflow more efficient and reliable.
The GitLab plain text editor now includes the same formatting options as the rich text editor. The plain text editor toolbar has been updated with a “More options” menu that provides access to advanced formatting tools like:
Both editors now have consistent button placement and separators, making it easier to switch between editing modes while maintaining access to familiar formatting options.
When troubleshooting vulnerabilities that have been automatically resolved, and later redetected, it can be helpful to compare the current pipeline to the pipeline where the vulnerability was resolved.
If a vulnerability is automatically resolved, the vulnerability notes in the vulnerability details page now include the pipeline ID where it occurred.
In GitLab 16.11, we added the artifacts:access keyword enabling users to control whether artifacts can be downloaded by all users with access to the pipeline, only users with the Developer role or higher, or no user at all.
In this release, you can now restrict who can download artifacts to only the Maintainer role or higher, giving you one more option for controlling who can download job artifacts.
We’re also releasing GitLab Runner 18.4 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.
chown command for runners with custom ConfigMap & security context constraints (SCC) fails after Operator v1.37.0 upgrade on OpenShift 4.16.27FF_RETRIEVE_POD_WARNING_EVENTS in GitLab 17.x.x releases due to early removal in 17.2FF_USE_FASTZIP does not enable fastzipUnsupportedOperation error when trying to stop Spot instances created with one-time requestsThe list of all changes is in the GitLab Runner CHANGELOG.
On August 21, 2025, GitLab 18.3 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
For 18.3, we’re excited to recognize Ahmed Kashkoush as our Notable Contributor!
Ahmed has been a standout contributor to the GitLab Web IDE through his Google Summer of Code participation this summer. He has consistently delivered essential Git operations, directly addressing long-standing community requests. His five substantial merge requests include commit and force push capabilities, update confirmation message, commit amend functionality, branch creation operations, and branch deletion features.
Beyond implementing new features, Ahmed resolved a 5+ year old feature request for amending existing commits from the Web IDE, a feature with 24 thumbs up from the community. His comprehensive branch management implementation brings the Web IDE closer to feature parity with local development environments, eliminating the need for users to switch between interfaces for basic Git operations. Ahmed’s work directly supports GitLab’s mission that “everyone can contribute” by making the Web IDE more accessible to developers.
Ahmed was nominated by Enrique Alcántara, Staff Frontend Engineer at GitLab, who served as his mentor throughout the Google Summer of Code program. “Ahmed shows dedication to solving real user pain points,” says Enrique. “His work demonstrates the impact a focused contributor can have on improving core GitLab functionality.”
Ahmed’s contributions showcase the power of mentorship and community collaboration in open source development and make GitLab more accessible to developers regardless of their local setup.
Thank you, Ahmed, for your exceptional contributions to GitLab’s Web IDE!
We are excited to announce the public beta release of the Duo Agent Platform for Visual Studio! With this release, Visual Studio users can now access Duo Agent Platform’s advanced AI-powered capabilities directly within their IDE.
The Duo Agent Platform brings two powerful features to your workflow:
Both features offer intelligent search across documentation, code patterns, and project information, empowering you to move seamlessly from quick edits to in-depth project analysis.
Try the Duo Agent Platform beta in Visual Studio today and experience a new level of productivity and AI assistance in your development workflow.
This release introduces embedded views, powered by GLQL, to general availability. Create and embed dynamic, queryable views of GitLab data directly where your work lives: in wiki pages, epic descriptions, issue comments, and merge requests.
Embedded views provide a stable foundation for teams to track work progress without navigating between multiple locations. Query issues, merge requests, epics, and other work items using familiar syntax, then display the results as tables or lists with customizable fields and filtering.
Embedded views transform static documentation into living dashboards that stay current with your project data, helping teams maintain context and improve collaboration across their workflows.
We welcome your feedback as we continue to enhance embedded views. Please share your thoughts and suggestions in our feedback issue.
Migration by direct transfer is now generally available. To migrate GitLab groups and projects between GitLab instances by direct transfer, you can use the GitLab UI or the REST API.
Compared to migration by uploading an export file, direct transfer:
On GitLab.com, migration by direct transfer is enabled by default. On GitLab Self-Managed and GitLab Dedicated, an administrator must enable the feature.
Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.
With our new fine-grained permissions for job tokens feature, you can now precisely control which specific resources a job token can access within your projects. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for jobs to complete their tasks when accessing your projects with the CI/CD job token.
We’re actively working to add additional fine-grained permissions to reduce reliance on long-lived tokens in pipelines.
You can now use GitLab Duo Code Review on GitLab Duo Self-Hosted. This feature is in beta on GitLab Duo Self-Hosted, with support for Mistral, Meta Llama, Anthropic Claude, and OpenAI GPT model families.
Use Code Review on GitLab Duo Self-Hosted to accelerate your development process without compromising on data sovereignty. When Code Review reviews your merge requests, it identifies potential bugs and suggests improvements for you to apply directly. Use Code Review to iterate on and improve your changes before you ask a human to review.
Provide feedback on Code Review in issue 517386.
Enforce consistent code review standards across your projects with custom instructions for GitLab Duo Code Review. Define specific review criteria for different file types using glob patterns, ensuring language-specific conventions are applied where they matter most.
With custom instructions, you can:
Simply create a .GitLab/duo/mr-review-instructions.YAML file in your repository with your custom instructions. GitLab Duo will automatically incorporate these instructions into its reviews, citing the specific instruction group when providing feedback.
Help us improve this feature by sharing your thoughts and suggestions in our feedback issue.
GitLab Duo Self-Hosted now enables you to bring your own model to use with GitLab Duo features. This feature is in beta, and available to all GitLab Self-Managed customers with GitLab Duo Enterprise. Instance administrators can configure any compatible model for use with a supported GitLab Duo feature.
This feature makes GitLab Duo Self-Hosted more flexible, but GitLab cannot guarantee that all GitLab Duo features will work with every compatible model. Instance administrators are responsible for validating the compatibility and performance of their chosen model. GitLab does not provide technical support for issues specific to your chosen model or platform.
You can now use a mix of GitLab AI vendor models and privately configured self-hosted models on GitLab Duo Self-Hosted. This feature is in beta and available on GitLab Self-Managed to all GitLab Duo Enterprise customers.
With hybrid models on GitLab Duo Self-Hosted, GitLab Self-Managed instance administrators can now choose between a self-hosted model and self-hosted AI gateway, or a GitLab AI vendor model and the GitLab-hosted AI gateway, on a feature-by-feature basis. This enables administrators to balance their security and scalability requirements. To provide feedback on hybrid model selection, see issue 561048.
Previously, the compliance violations report provided a high-level view of merge request activity for all projects in a group. The available compliance violations related to separation of duty concerns, such as:
However, user feedback revealed that users found violation classifications confusing and difficult to understand, due to not aligning well with actual compliance use cases.
GitLab 18.3 significantly enhances the violations report by expanding beyond separation of duty to include violations of compliance controls and requirements in compliance frameworks. Each custom compliance framework control has an associated audit event that provides detailed context about violations: who committed the violation, when it occurred, and how to fix it. This includes the user’s name and IP address, plus actionable remediation suggestions.
These improvements give compliance managers more powerful and relevant context to ensure their organization adheres to specific compliance frameworks, while providing reassurance that non-compliance can be effectively identified, rectified, and prevented.
We’re excited to announce additional source control functionalities in the Web IDE. You can manage your Git workflow more efficiently without leaving your browser. In the Source Control panel, you can now:
These enhancements bring Git operations right to your fingertips. For information about the functionalities available to you, see Use source control.
Secrets stored in AWS Secrets Manager can now be easily retrieved and used in CI/CD jobs. Our new integration with AWS simplifies the process of interacting with AWS Secrets Manager through GitLab CI/CD, helping our AWS customers streamline build and deploy processes!
Thank you to Markus Siebert and Henry Sachs who helped build this feature through GitLab’s Co-Create program!
The custom admin role brings granular permissions to the Admin area for GitLab Self-Managed and GitLab Dedicated instances. Instead of granting full access, administrators can now create specialized roles that access only the specific functions needed by users. This feature helps organizations implement the principle of least privilege for administrative functions, reduce security risks from overprivileged access, and improve operational efficiency.
If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, see the feedback issue.
GitLab Self-Managed customers with GitLab Duo Enterprise can now use Anthropic Claude 4 with GitLab Duo Self-Hosted. Claude 4 is supported on AWS Bedrock. Open source OpenAI GPT OSS 20B and 120B have been added as experimental models, and are available on vLLM, Azure OpenAI, and AWS Bedrock. To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.
We’re excited to announce significant improvements to the group overview in Your work, designed to streamline how you discover and access your groups. The new tabbed interface features a Member tab, which provides a comprehensive view of accessible groups, and an Inactive tab to track groups pending deletion. We’ve also streamlined group management by adding Edit and Delete actions to the list view for users with appropriate permissions. We hope that these improvements make it easier to find and manage the groups that matter most to you.
We value your feedback on this update! Join the discussion in epic 18401 to share your experience with the new navigation system.
We’ve upgraded the Admin area projects list to provide a more consistent experience for GitLab administrators:
This update brings the administrator experience in line with GitLab design standards, and adds important safety features to protect your data. Future enhancements to project management will automatically appear in all project lists throughout the platform.
Being able to trace a dependency back to its source is important, especially for
vulnerability remediation. Previously, the Dependency Scanning analyzer sometimes
linked to job artifacts which were deleted when they expired. This made it
difficult to trace back to the source of the dependency.
The Dependency Scanning analyzer can now link to the project file that introduced
the dependency. With this option enabled, links in the dependency list and
vulnerability report are reliable.
Users may enable this functionality by setting DS_FF_LINK_COMPONENTS_TO_GIT_FILES=true
for the Dependency Scanning job.
Users may now choose which source of license information has priority - the GitLab License database or a CycloneDX SBOM report. This provides users with more flexibility in sourcing license information for their open-source dependencies. Users who wish to define the source of license information may use the Security Configuration UI to make a selection. By default we use the SBOM data as a source for license information.
GitLab 18.3 introduces several improvements to the dynamic analysis security testing job output.
This improved job output provides clear, structured information that helps you understand scan results and troubleshoot failures.
Each section of the job output is concise and intuitive, with a link to our troubleshooting documentation at the bottom of the output.
To override concise job output, set DAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true" in your DAST configuration.
Enterprise users want to manage their compliance frameworks and security policies across multiple top-level groups. This is often the case when all groups in an instance:
With GitLab 18.3, compliance and security policy management is now available in beta for GitLab Self-Managed instances. You can now create, configure, and allocate compliance frameworks and security policies from a single top-level group and enforce them across all of the other top-level groups across your GitLab Self-Managed instance.
When you use a compliance and security policy top-level group, you have a single source of truth where you can manage and edit your compliance frameworks and security policies. Group admins can then apply these compliance frameworks and security policies to all the projects within those groups.
When you manage key frameworks and policies from the chosen top-level compliance and security policy group, it’s easier to manage and enforce key compliance and security needs across your GitLab Self-Managed instance. However, groups still retain the ability to create their own compliance frameworks and security policies to address specific situations or workflows that can arise in those groups.
This feature is for GitLab Self-Managed customers because GitLab.com and GitLab Dedicated customers are already able to manage policies centrally within a single top-level group or namespace.
Workspaces now use shallow cloning to reduce startup time. During initialization, GitLab downloads only the latest commit history instead of the full Git history. After the workspace starts, Git converts the shallow clone to a full clone in the background.
This feature applies automatically to all new workspaces, no configuration is required, and it doesn’t affect your development workflow.
The GitLab CLI (glab) now includes a new top-level command, opentofu.
The opentofu command is aliased to terraform and tf commands to assist with GitLab-managed
OpenTofu and Terraform states.
The following commands have been added:
glab opentofu init: Initialize the state backend locally.glab opentofu state list: List all states in a project.glab opentofu state download: Download the latest state or a specific version.glab opentofu state delete: Delete the entire state or a specific version.glab opentofu state lock: Lock a state.glab opentofu state unlock: Unlock a stateTo manage state with the opentofu command, you must have at least glab 1.66 or later.
GitLab now fully supports Kubernetes version 1.33. If you deploy your apps to Kubernetes, you can upgrade your connected clusters to the most recent version and take advantage of all its features.
For more information, see the Supported Kubernetes versions for GitLab features.
OAuth applications can now seamlessly integrate with your organization’s single sign-on requirements. Previously, users had to authenticate twice: first with GitLab, then with SSO, creating unnecessary friction and complexity.
Now, OAuth applications can specify a parameter in their authorization requests to automatically trigger SSO authentication when required. This provides:
Your OAuth integrations now respect SSO policies automatically, eliminating confusing authentication workflows while maintaining security.
Administrators can now set the default behavior for unique domains on new GitLab Pages sites. By default, new Pages sites use unique domain URLs (like my-project-1a2b3c.example.com) to prevent cookie sharing between sites.
With this new setting for the instance, you can set new Pages sites to use path-based URLs (like my-namespace.example.com/my-project) by default. This helps organizations align GitLab Pages behavior with their workflows and security requirements.
Users can still override this setting for individual projects, and existing Pages sites remain unaffected.
This release introduces an enhanced wiki experience with three key improvements: you can now subscribe to wiki pages, view wiki comments while editing a page, and sort wiki page comments.
These enhancements help teams collaborate more effectively on documentation by letting you:
With these updates, your GitLab wiki becomes living documentation that evolves alongside your projects through direct feedback and discussion.
You can now bulk edit more epic attributes in a group. In addition to labels, you can now update assignee, health status, subscription, confidentiality, and milestone for multiple epics at once.
This enhancement makes it faster to manage large numbers of epics by letting you apply the same changes across multiple epics simultaneously.
Use the Projects REST API to programmatically enable or disable the Pipeline execution policy setting in security policy projects with the new spp_repository_pipeline_access field. Previously, this setting could only be managed through the GitLab UI. With this enhancement, you can now:
GET the current Pipeline execution policy status.PUT to enable or disable the setting programmatically.This improvement enables better automation and integration workflows for teams managing security policies at scale.
In the vulnerability report for projects and groups, you can now group the vulnerabilities by their OWASP Top 10 2021 category. Available for GitLab.com and GitLab Dedicated instances only.
Scan execution policy templates help you quickly create scan execution policies based on common use cases. Choose from three templates:
Once you select a template, choose which GitLab security scans to enable with the template to get up and running immediately. If you have more advanced use cases, you can switch to the custom configuration to extend the policy with specific branch patterns, pipeline sources, and more.
GitLab Ultimate now provides comprehensive audit events for security policy management, with events organized and centralized within each security policy project.
Security teams can now:
New audit events include:
This enhancement strengthens your security posture by ensuring you have access to policy changes, configuration errors, and enforcement gaps, enabling faster incident response and thorough auditing capabilities.
The new Service Account & Access Token Exceptions feature allows you to designate service accounts and access tokens that can bypass merge request approval policies when necessary. This eliminates friction for known automations, while preserving security controls.
Key capabilities include:
This enhancement maintains strict security policies with flexibility for modern DevOps automation needs, eliminating custom workarounds while preserving governance controls.
GitLab now automatically detects and respects the SessionNotOnOrAfter attribute in SAML assertions from your Identity Provider (IdP).
When this attribute is present, GitLab sets user sessions to expire at the time specified by your IdP,
ensuring consistent session management across your organization. This feature requires no configuration changes - if your IdP provides the attribute, GitLab automatically honors the specified expiration time.
By default, GitLab automatically generates an email address for new service accounts. Organizations can now assign a custom email address for service accounts through the UI. Previously, custom email configuration was only possible through the Service Accounts API. This change allows organizations to better route notifications to designated email addresses.
GitLab 18.3 introduces enterprise user enhancements that give organizations greater control over user privacy and lifecycle management.
Group owners can now delete enterprise users in their namespace with the Users API. This destructive action unlinks user contributions and associates them with a system-wide Ghost user. These option is particularly valuable for cleaning up users erroneously created with automated SCIM imports or managing federated environments where usernames and emails need to be repurposed.
Additionally, organizations can now hide enterprise user emails on their user profiles, providing broader email privacy enforcement for all enterprise users.
GitLab now displays a security warning in the UI when a user uploads a weak SSH key. This warning appears for older key types or keys with insufficient bit length (less than 2048 bits). This change helps educate users about SSH key security best practices and encourages the use of stronger cryptographic keys.
We’re also releasing GitLab Runner 18.3 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.
incorrect username or password error message.*_get_sources hooks usage between none and empty Git strategiesapp.kubernetes.io/instance labelgitlab-runner namespaceThe list of all changes is in the GitLab Runner CHANGELOG.
On July 17, 2025, GitLab 18.2 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Markus Siebert, a Platform Engineer at DB Systel GmbH, is leading the community effort to bring native AWS Secrets Manager support to GitLab CI/CD, addressing a critical enterprise need for secure secret management in pipelines. With an impressive 172 documented activities in just 6 weeks, Markus has been working tirelessly on implementing both AWS Secrets Manager and AWS Systems Manager Parameter Store support through multiple merge requests including Add functionality to retrieve secrest from AWS Secrets Manager, Add GitLab CI config entry for AWS SSM ParameterStore, and Documentation for AWS Secrets Manager.
“Markus’s work directly enables GitLab users in AWS environments to securely manage their CI/CD secrets without relying on third-party tools or custom scripts. This is especially valuable for enterprise users who have standardized on AWS services,” says Aditya Tiwari, Senior Backend Engineer, Secure at GitLab, who nominated Markus.
Markus’s dedication to seeing this feature through - from initial implementation to documentation - while actively maintaining and improving merge requests based on feedback, exemplifies the best of community contribution and demonstrates the power of community-driven development in making GitLab better for AWS users.
This contribution was delivered through the GitLab Co-Create Program.
Thanks to Markus for your valuable contributions to GitLab!
The Duo Agent Platform brings agentic chat and agent flows directly into VS Code and JetBrains IDEs, enabling natural conversation-based interaction with your codebase and GitLab projects.
Agentic chat is designed for quick, conversational tasks like creating and editing files, searching across your codebase with pattern matching and grep, and getting immediate answers about your code. Agent flows handle larger implementations and comprehensive planning, taking high-level ideas from concept to architecture while accessing GitLab resources including issues, merge requests, commits, CI/CD pipelines, and security vulnerabilities. Both provide intelligent search capabilities for documentation, code patterns, and project discovery to help you accomplish everything from quick edits to complex project analysis.
The platform also supports Model Context Protocol (MCP) for connecting to external data sources and tools, allowing AI features to leverage context beyond GitLab.
Learn more in our blog GitLab Duo Agent Platform Public Beta: Next-gen AI orchestration and more.
To get started, see the Duo Agent Platform documentation, VS Code setup guide, and JetBrains setup guide.
Move beyond the basic open/closed system with configurable status that lets you track work items through your team’s actual workflow stages.
Instead of relying on labels, you can now define custom statuses that accurately reflect your process. With configurable statuses, you can:
Custom workflow statuses also support quick actions in comments and automatically syncs with GitLab’s open/closed system.
Help us improve this feature by sharing your thoughts and suggestions in our feedback issue.
Managing code reviews across multiple projects can be overwhelming when you’re juggling dozens of merge requests as both an author and reviewer.
The new merge request homepage transforms how you navigate your review workload by intelligently prioritizing what needs your attention right now, with two powerful viewing modes:
The Active tab shows merge requests requiring attention, Merged displays recently completed work, and Search provides comprehensive filtering capabilities.
The new homepage also expands your visibility by combining both authored and assigned merge requests, ensuring you never miss work that’s been delegated to you.
Container registries are critical infrastructure for modern DevSecOps teams. However, even with protected container tags, organizations still face a challenge: After a tag is created, users with sufficient permissions can alter it. This creates risks for teams that rely on specific tagged versions of container images for production stability. Any modification—even by authorized users—can introduce unintended changes or compromise deployment integrity.
With immutable container tags, you can protect container images from unintended changes. After a tag is created that matches an immutable rule, no one can modify the container image. You can now:
Immutable container tags require the next-generation container registry, which is enabled by default on GitLab.com. For GitLab Self-Managed instances, you must enable the metadata database to use immutable container tags.
GitLab Premium and Ultimate users can now change the availability of Code Suggestions and GitLab Duo Chat in the IDE for groups and projects. Previously, you could change the availability for the instance or top-level group only.
The compliance center is the central location for compliance teams to manage their compliance status reporting, violations reporting, and compliance frameworks for their group.
The new group overview compliance dashboard gives compliance managers an aggregated view on compliance information across all of the projects in a group. This first iteration displays the following information:
With this new group overview, compliance managers now have a single unified view that provides them with a clear high-level picture, of their compliance posture.
GitLab administrators can now map enabled workspace Kubernetes agents for the instance. Users can then create workspaces from any group or project in that instance.
This significantly increases workspace scalability by allowing organizations to provision workspace Kubernetes agents once, and make those agents accessible to all current and future projects across the entire instance.
To communicate the state and progress of your vulnerability management efforts to other stakeholders, you can now export the security dashboard for each project or group as a PDF document.
In large organizations where compliance is critical, teams often struggle with fragmented policies scattered across multiple projects and groups. Without centralized visibility, ensuring consistent enforcement becomes a time-consuming challenge while increasing compliance risk.
Centralized security policy management introduces a unified approach to creating, managing, and enforcing security policies across your entire GitLab organization through a single designated compliance and security policy (CSP) group. This allows security teams to:
This beta release establishes the foundational framework for centralized policy management, with support for all existing security policy types, configurable for groups, projects, or instance.
You can now use Mistral Small on GitLab Duo Self-Hosted. This model is available on GitLab Self-Managed instances, and is the first fully compatible open source model for GitLab Duo Chat and Code Suggestions on GitLab Duo Self-Hosted.
Administrators can now reassign contributions from placeholder users to active users without user confirmation. This feature addresses a key challenge for larger organizations where the process stalled when users did not check their emails to approve reassignments.
On GitLab instances where user impersonation is enabled, administrators can maintain data integrity while streamlining user management workflows. Users still receive notification emails after the reassignment is complete, ensuring transparency throughout the process.
Previously, administrators could reassign contributions and memberships from placeholder users to active users only.
On GitLab Self-Managed, administrators can now also reassign contributions and memberships from placeholder users to inactive users. This feature permits you to preserve the contribution history and membership information of blocked, banned, or deactivated users on your GitLab instance.
Administrators must first enable this setting and, when enabled, this setting streamlines user management by skipping user confirmation during reassignment while maintaining secure access control.
Container Scanning now ships with Linux Arm64 container image variants. When running
on a Linux Arm64 runner, the analyzer will no longer require emulation, resulting in a faster
analysis. In addition, you can now scan multi-architecture images by
setting the TRIVY_PLATFORM environment variable to the platform you want to scan.
GitLab 18.2 brings improved archive file scanning support to Container Scanning. If a vulnerability in a particular package is found in multiple images, you now see a vulnerability attributed to each scanned image.
Composition Analysis now supports Static Reachability for JavaScript libraries. You can use the data produced by static reachability as part of your triage and remediation decision making. Static reachability data can also be used with EPSS, KEV, and CVSS scores to provide a more focused view of your vulnerabilities.
Previously, the DAST_AUTH_SUCCESS_IF_AT_URL variable required an exact URL match to verify successful authentication. This worked well for applications with static landing pages, but posed difficulties for applications where post-login URLs contain dynamic elements for each login.
Now, you can use wildcard patterns in the DAST_AUTH_SUCCESS_IF_AT_URL variable to match dynamic URL patterns. This enhancement provides the flexibility needed to verify authentication success even when the exact URL changes between sessions.
Dynamic Analysis now supports time-based one-time password (TOTP) multi-factor authentication.
You can run DAST scans on projects with TOTP MFA enabled to ensure comprehensive security testing. This enhancement delivers more accurate scan results by testing applications in configurations that mirror production environments where MFA is deployed.
Previously, there was no way to temporarily deactivate streaming to an audit streaming destination. You might want to do this for a number of reasons, including to troubleshoot stream connectivity or to make changes to configuration without deleting the configuration and starting again.
With GitLab 18.2, we’ve added the ability to toggle an audit stream as active or inactive. When the audit stream is inactive, audit events are no longer streamed to the chosen destination. When reactivated, audit events are again streamed to the chosen destination.
Previously, certain audit streaming destinations did not have all of the available filtering capability.
We now support filter functionality for all destinations via the UI, including the ability to filter:
This change also means that audit event destinations such as AWS and GCP can now filter through audit events.
You now have full control over which metadata appears when you view your list of work items, making it easier to focus on the information that matters most to you.
Previously, all metadata fields were always visible, which could make scanning through work items overwhelming. Now you can customize your view by turning on or off specific fields like assignees, labels, dates, and milestones.
You can now choose how epics open from the list page with a new toggle that switches between drawer view and full-page navigation.
Use the drawer to quickly review epic details while maintaining context of your epic list, or open the full page when you need more screen space for detailed editing and comprehensive navigation.
You can now assign milestones directly to epics, creating a natural planning cascade from strategic initiatives down to execution. This enhancement helps you align longer-term planning cadences, like quarterly planning or SAFe program increments, with epics. At the same time, you can keep iterations focused on development sprints.
With this clear hierarchy in place, you can reduce administrative overhead and gain better visibility into how your strategic initiatives progress against organizational timeframes.
You can now assign epics to individuals, making it clear who is responsible for overseeing strategic initiatives. Epic assignees help you identify ownership at the portfolio level, enabling faster decision-making and clearer accountability for long-term objectives. Teams can quickly see who to contact about epic progress, dependencies, or scope changes.
This release introduces enhanced sorting and pagination for GLQL views, making it easier to work with large datasets.
You can now sort by key fields including due dates, health status, and popularity to quickly find the most relevant items. The new “Load more” pagination system provides better control over data loading, replacing overwhelming full-page results with manageable chunks that load on demand.
These improvements help teams efficiently navigate complex project data and focus on what matters most at any given moment.
You can now reference issues, epics, and work items using a unified [work_item:123] syntax in GitLab Flavored Markdown. This new syntax works alongside existing reference formats like #123 for issues and &123 for epics, and supports cross-project references with [work_item:namespace/project/123].
The plain text editor also includes a new preference to maintain cursor indentation when you press Enter, making it easier to write structured content like nested lists and code blocks.
Previously, the CSV export of the vulnerability report did not include vulnerability IDs. You can now find the ID of each vulnerability listed in the CSV export.
Users can now filter data in the vulnerability report to include only reachable vulnerabilities. Reachable vulnerabilities represent vulnerabilities that are both:
You can now use the GraphQL API to determine the pipeline when the vulnerability was introduced and when it was last detected. The Vulnerability GraphQL API now includes:
initialDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was introduced, such as the author’s user name.latestDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was removed, such as the commit SHA.Previously, teams using GitFlow often faced approval deadlocks when merging release/* branches to main,
as most contributors had already participated in release development and then couldn’t serve as approvers.
Branch pattern exceptions in merge request approval policies solve this by automatically bypassing approval requirements for specific source-target branch combinations. Configure strict approvals for feature-to-main merges while allowing streamlined release-to-main workflows.
Key capabilities:
release/* or hotfix/* that bypass approval requirementspolicy.yml file.This eliminates the need for complex workarounds while preserving the security benefits of merge request approval policies for standard development workflows.
Previously, it was difficult to determine whether a dependency was a direct dependency, or a transient dependency imported by a descendant of the dependency.
You can now determine whether a library is primarily or transitively imported using the new dependency paths feature. You can find dependency paths on the project and group dependency list as well as in the vulnerability details. This capability allows developers to determine the most efficient path to a fix depending on how the library is imported.
GitLab now supports service account tokens in the credentials inventory, giving you better visibility and control over the various authentication methods used across your software supply chain. The credentials inventory provides a complete picture of credentials used across your organization.
AppSec teams need comprehensive visibility into their organization’s security posture across all assets. Previously, GitLab’s security workflows focused primarily on project-level scanner configuration and project-level vulnerabilities, making it difficult to understand coverage gaps and make efficient, risk-based prioritization decisions.
Security Inventory provides a centralized view of the security posture across your GitLab instance, enabling AppSec teams to:
This feature helps bridge the gap between individual project security and organization-wide security strategy, giving you the asset inventory foundation needed for effective security program management.
The custom admin role brings granular permissions to the Admin Area for GitLab Self-Managed and GitLab Dedicated instances. Instead of granting full access, administrators can now create specialized roles that access only the specific functions needed by users. This feature helps organizations implement the principle of least privilege for administrative functions, reduce security risks from overprivileged access, and improve operational efficiency.
We’re actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.
Previously, trigger jobs using strategy:depend had limitations when dealing with complex pipeline states such as manual jobs,
blocked pipelines, or retried pipelines with changing statuses during execution.
This could make it seem like the downstream pipeline was actively running, when it was actually blocked on a manual job.
The new strategy:mirror keyword provides more nuanced status reporting by mirroring
the exact real-time status of the downstream pipeline. Statuses include intermediate states like
running, manual, blocked, and canceled . This gives teams complete visibility into
the current state of their downstream pipeline without breaking the existing workflow.
We’re also releasing GitLab Runner 18.2 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.
FF_USE_DUMB_INIT_WITH_KUBERNETES_EXECUTORubi-fips image is not the default helper image flavor for GitLab Runner FIPSThe list of all changes is in the GitLab Runner CHANGELOG.
On June 19, 2025, GitLab 18.1 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Chaitanya Sonwane drives GitLab’s security capabilities through consistent authentication improvements. With 13 merged contributions in 2025, his work enhanced credential inventory filtering, service account management, and work items usability. He previously delivered a key feature in GitLab 17.11 with token statistics for service accounts, which provides “at a glance” information that makes it easier to manage service accounts. Chaitanya is now improving work item list sort settings to be context specific, further enhancing the user experience in GitLab’s Product Planning.
Chaitanya’s work directly strengthens security for GitLab organizations and provides better visibility into service account usage across projects. Teams can now track and rotate credentials more effectively. This reduces the risk of orphaned or forgotten credentials that create security vulnerabilities.
“Chaitanya’s contributions to the credential inventory and service accounts are both very valuable contributions in the security space,” says Eduardo Sanz-Garcia, Senior Frontend Engineer for the Authentication group, Software Supply Chain Security stage. Eduardo supported the nomination from GitLab’s Authentication team.
“Chaitanya was instrumental in the implementation of the token statistics concept,” Eduardo adds. “His credential inventory work delivered a highly requested feature to enhance the tractability and monitoring of credentials. This was a great contribution!”
Chaitanya is a Software Engineer at TATA AIG. He proactively tackles security issues and follows up consistently on improvements to his own contributions.
Thanks to Chaitanya for contributing to GitLab’s security foundation and the rest of the product!
The Maven virtual registry simplifies Maven dependency management in GitLab. Without the Maven virtual registry, you must configure each project to access dependencies from Maven Central, private repositories, or the GitLab package registry. This approach slows builds with sequential repository queries and complicates security auditing and compliance reporting.
The Maven virtual registry addresses these issues by aggregating multiple upstream repositories behind a single endpoint. Platform engineers can configure Maven Central, private registries, and GitLab package registries through one URL. Intelligent caching improves build performance and integrates with GitLab’s authentication systems. Organizations benefit from reduced configuration overhead, faster builds, and centralized access control for improved security and compliance.
The Maven virtual registry is currently available in beta for GitLab Premium and Ultimate customers on both GitLab.com and GitLab Self-Managed. The GA release will include additional capabilities, such as a web-based user interface for registry configuration, shareable upstream functionality, lifecycle policies for cache management, and enhanced analytics. Current beta limitations include a maximum of 20 virtual registries per top-level groups and 20 upstreams per virtual registry, with API-only configuration available during the beta period.
We invite enterprise customers to participate in the Maven virtual registry beta program to help shape the final release. Beta participants will receive early access to the capabilities, direct engagement with GitLab product teams, and priority support during evaluation. To join the beta program, express interest and provide your use case details in issue 498139, and share feedback and suggestions in issue 543045.
Duo Code Review is now generally available and ready for production use. This AI-powered code review assistant transforms the traditional code review process by providing intelligent, automated feedback on your merge requests. It helps identify potential bugs, security vulnerabilities, and code quality issues before human reviewers get involved, making the entire review process more efficient and thorough. It includes:
@GitLabDuo in merge request comments to get targeted feedback on specific changes or questions.To request a code review:
@GitLabDuo as a reviewer using the /assign_reviewer @GitLabDuo quick action, or assign GitLab Duo directly as a reviewer.@GitLabDuo in comments to ask specific questions or request focused feedback on any discussion thread.Duo Code Review helps teams maintain higher code quality standards while reducing the time spent on manual review cycles. By catching issues early and providing educational feedback, it serves as both a quality gate and a learning tool for development teams.
**Watch an overview of Duo Code Review in action from our beta release.
Share your experience and feedback in issue 517386 to help us continue improving this feature.
GitLab.com now performs a secure check of your account credentials when you sign in to GitLab.com. If your password is part of a known leak, GitLab displays a banner and sends you an email notification. These notifications include instructions for how to update your credentials.
For maximum security, GitLab recommends using a unique, strong password for GitLab, enabling two-factor authentication, and regularly reviewing your account activity.
Note: This feature is only available for native GitLab usernames and passwords. SSO credentials are not checked.
You can now achieve SLSA Level 1 compliance using GitLab’s new CI/CD components for signing and verifying SLSA-compliant artifact provenance metadata generated by GitLab Runner. The components wrap Sigstore Cosign functionality in reusable modules that can be easily integrated into CI/CD workflows.
Exact code search (in beta) now consolidates multiple search results from the same file into a single view. This improvement:
With this change, finding and understanding code patterns across your repositories is now more efficient.
accessLevels argument for projectMembers in GraphQL APIWe’re excited to announce the addition of the accessLevels argument to the projectMembers field in our GraphQL API.
Use this argument to filter project members by access level directly from an API call.
Previously, you had to fetch an entire list of project members and apply filters locally, which added significant computational overhead.
Now, analyzing project permissions and generating ownership graphs is faster and more resource-efficient.
This enhancement is particularly valuable to organizations managing large-scale deployments with complex permission structures.
The DAST analyzer now automatically ingests the same default secret detection rules that are used by GitLab’s Secret Detection analyzer. This improvement ensures consistency in the types of secrets detected by both.
Name for external custom controlsPreviously, you couldn’t define a name for an external custom control when creating a custom compliance framework, which made it difficult to identify external controls when listed alongside GitLab controls.
We’ve now added a Name field as part of the workflow when defining an external custom control, so you can
create multiple external custom controls and clearly define each one with its own unique name.
When creating a compliance framework, you can specify a maximum of 50 requirements.
However, it becomes very difficult to navigate a compliance framework with this many requirements because they consume a lot of space in the user interface.
In this release, we have introduced pagination for requirements to make it easier for users to navigate, find, and select requirements when there is a large number of them attached to a compliance framework.
We have continued to improve the UI performance and filtering options provided by the compliance center. In this release, we have:
By delivering these improvements, we continue to ensure that the compliance center and associated functions continue to perform at scale for customers who regularly use the compliance center.
Controls in the compliance status report have three different statuses:
No matter the number of controls that are attached to the requirement, if at least one control was ‘pending’, the entire requirement row was shown as ‘pending’ as well. This deviated from the established UX pattern for visualizing failed controls, where the requirement would show the number of controls associated with the requirement, even when there was at least one control that fails.
To provide further context and information for ‘pending’ controls, we now provide a hover over pop-up on the requirement row status, with the status of each control listed. You can now understand which controls are pending, and which are potentially succeeding and failing, rather than just seeing a single status for ‘pending’.
When you review a merge request, it can be valuable to see all of the comments and feedback you’ve provided before you submit your review. Previously, this experience was fragmented between the final comment and an additional pop-up to see your pending comments, making it hard to get the complete overview.
When conducting code reviews, you can now access a dedicated drawer that consolidates all your pending draft comments in one organized view. The enhanced review panel moves the review submission interface to a more accessible location, and provides a numbered badge showing your pending comment count. When you open the panel, you’ll see all your draft comments organized in a scrollable list, making it easier to review and manage your feedback before submitting.
GitLab now provides enhanced validation for CODEOWNERS files that goes beyond basic syntax checking. When viewing a CODEOWNERS file, GitLab automatically runs comprehensive validations to help you identify both syntax and permission issues before they affect your merge request workflows.
The enhanced validation checks the first 200 unique user and group references in your CODEOWNERS file, and verifies that:
This proactive validation helps prevent approval workflow disruptions by catching configuration issues early, ensuring your Code Owners can actually fulfill their review responsibilities when merge requests are created.
postStart eventsGitLab workspace now supports custom postStart events in your devfile, allowing you to define commands that automatically execute after workspace startup. Use these events to:
The GitLab Workflow extension for VS Code now displays job logs from downstream pipelines directly in your editor. Previously, viewing logs from child pipelines required switching to the GitLab web interface.
This feature was developed through the GitLab Co-create program. Special thanks to Tim Ryan for making this contribution!
GitLab automatically deactivates access tokens after they expire or are revoked. You can now review these inactive tokens. Previously, access tokens were no longer visible after they became inactive. This change enhances traceability and security of these token types.
We’ve made a significant improvement to GitLab Query Language (GLQL) views. You can now use epic as a type in your queries to search for epics across groups, and query by parent epic!
This is a huge step forward for our planning and tracking capabilities, making it easier than ever to query and organize at the epic level.
We have added PHP support to GitLab Advanced SAST. To use this new cross-file, cross-function scanning support, enable Advanced SAST. If you have already enabled Advanced SAST, PHP support is automatically activated.
To see which types of vulnerabilities Advanced SAST detects in each language, see the Advanced SAST coverage page.
The dependency lists now supports filtering by a component’s version number. You can select multiple versions
(for example, version=1.1,1.2,1.4 ) but ranges are not supported. This feature is available in both groups and projects.
Security teams often strike a delicate balance between security assurance and developer experience. It’s critical to ensure security scans are properly enforced, but security analyzers can require specific inputs from development teams to properly execute. With variable precedence controls, security teams now have granular control over how variables are handled in pipeline execution policies through the new variables_override configuration option.
Using this new configuration, you can now:
CS_IMAGE).SAST_EXCLUDED_PATHS while blocking high risk variables like SAST_DISABLED.AWS_CREDENTIALS, while allowing project-specific overrides where appropriate through project-level CI/CD variables.This powerful feature supports two approaches:
allow: false): Lock all variables except specific ones you list as exceptions.allow: true): Allow variables to be customized, but restrict critical risks by listing them as exceptions.To improve traceability and troubleshooting when a pipeline execution policy is the source of an CI/CD job, we’re also introducing job logs to help developers and security teams identify the jobs executed by a policy. The job logs provide details on the impact of variable overrides to help you understand if variables are overridden or locked by policies.
Real-world impact
This enhancement bridges the gap between security requirements and flexibility for developers:
By solving this critical variable control challenge, GitLab enables organizations to implement robust security policies without sacrificing the flexibility teams need to deliver software efficiently.
Established GitLab instances can often have large numbers of human and bot users. You can now filter the users list in the Admin area by user type. Filtering users can help you:
GitLab now supports ORCID identifiers in user profiles, making GitLab more accessible and valuable for researchers and the academic community. ORCID (Open Researcher and Contributor ID) provides researchers with a persistent digital identifier that distinguishes them from other researchers and supports automated linkages between researchers and their professional activities, ensuring their work is properly recognized.
This feature was developed as a community contribution by Thomas Labalette and Erwan Hivin, master students at Artois University, under the supervision of Daniel Le Berre, addressing a long-standing request from the academic community.
You can now subscribe to notifications for pipeline events triggered by service accounts. Notifications are sent when the pipeline passes, fails, or is fixed. Previously, these notifications were only sent to the service account’s email address if the service account has a valid custom email address.
Thank you Densett, Gilles Dehaudt, Lenain, Geoffrey McQuat, and Raphaël Bihoré for your contribution!
Previously, you had to manually resolve detected vulnerabilities with these Common Weakness Enumeration (CWE) identifiers:
Now, Duo Vulnerability Resolution can automatically fix these vulnerabilities.
We’re also releasing GitLab Runner 18.1 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.
404 response when they request jobs.The list of all changes is in the GitLab Runner CHANGELOG.
On May 15, 2025, GitLab 18.0 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Michael Hofer champions GitLab’s open source mission as both a top contributor and community leader. With over 50 contributions this year, his work strengthened GitLab’s Geo features and Secrets Manager, based on OpenBao. He topped the April Hackathon while supporting fellow contributors and leading community projects.
“I truly appreciate that everyone can contribute to GitLab!” says Michael. “The team is great to work with, it’s a lot of fun, and everyone is super helpful, especially when we team up across open source initiatives like OpenBao and SLSA.”
Michael is the CTO at Adfinis, an international IT service provider specializing in planning, building, and running mission critical open source workloads. He is passionate about fostering collaboration and promoting open source solutions across organizations.
Recently, Adfinis participated in GitLab’s Co-Create program, which pairs organizations with GitLab’s product and engineering teams to build GitLab together. “We highly recommend Co-Create to all organizations,” Michael says. “It led to a number of cool contributions, including rootless Podman builds, Glimmer syntax highlighting, and other improvements.”
“The Geo Team really appreciates and enjoys working with Michael,” says Lucie Zhao, Engineering Manager at GitLab, who nominated Michael for the award. “With his excellent contributions over the last few milestones, he has become the most well-known community contributor within our team.”
GitLab team members Lee Tickett, Chloe Fons, and Alex Scheel supported the nomination. Alex adds, “Michael’s leadership in OpenBao has enabled us to effectively collaborate in bringing forward a secrets management solution for our customers, with the transparency that aligns with our GitLab values.”
Thanks to Michael and the Adfinis team for co-creating GitLab!
We’re excited to announce GitLab Premium with Duo and GitLab Ultimate with Duo. GitLab Premium and Ultimate now include AI-native features.
GitLab’s AI-native features include Code Suggestions and Chat within the IDE. Development teams can use these features to:
You can now use Repository X-Ray with Code Suggestions on GitLab Duo Self-Hosted. This feature is in beta for GitLab Duo Self-Hosted, and is generally available on GitLab Self-Managed instances.
Duo Code Review provides valuable insights during the review process, but currently requires you to manually request reviews on each merge request.
You can now configure GitLab Duo Code Review to run automatically on merge requests by updating your project’s merge request settings. When enabled, Duo Code Review automatically reviews merge requests unless:
Automatic reviews ensure that all code in your project receives a review, consistently improving code quality across your codebase.
Code Suggestions now includes prompt caching. Prompt caching significantly improves code completion latency by avoiding the re-processing of cached prompt and input data. The cached data is never logged to any persistent storage, and you can optionally disable prompt caching in the GitLab Duo settings.
Duo Code Review now provides more comprehensive context for improved analysis. The key improvements are:
These enhancements reduce inaccurate suggestions and deliver more relevant and higher quality code reviews.
In this release we’ve improved the placeholder users mapping experience by narrowing down the user selection dropdown to only Enterprise users associated with the top-level group. Previously, when reassigning users’ contributions after an import to GitLab.com, you would see in the dropdown list all active users on the platform, making it difficult to identify the correct user, especially when SCIM provisioning had modified usernames. Now, if your top-level group uses the Enterprise users feature, the dropdown list will display only users claimed by your organization, significantly reducing the potential for errors during user reassignment. The same scoping is also applied to CSV-based reassignment, preventing accidental assignment to users outside your organization.
The GitLab for Slack app now supports multiple workspaces for GitLab Self-Managed and GitLab Dedicated customers. Enabling multiple workspaces allows organizations with federated Slack environments to maintain seamless GitLab integrations across all their workspaces. To enable support for multiple workspaces, configure the GitLab for Slack app as an unlisted distributed app.
In GitLab 18.0, when you delete a top-level group, placeholder users associated with the group are deleted as well. If placeholder users are associated with other projects, they are only removed from the top-level group. This way, unnecessary placeholder users are removed without disrupting the history or attributions of other projects.
GitLab Dedicated customers with strict security requirements and compliance obligations require the highest level of protection for their development environments. Today, we’re introducing Internal Releases, a new private release that allows us to remediate GitLab Dedicated instances for critical vulnerabilities before public disclosure, ensuring GitLab Dedicated customers are never exposed to them. This new capability delivers immediate protection for critical vulnerabilities found in GitLab parallel to response for GitLab.com. This new process does not require customer action.
In GitLab 18.0, we are enabling event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption. For detailed instructions on how to adjust data sharing settings, please refer to our documentation.
Project and group delayed deletion is now available for all GitLab users, including those on our Free tier. This essential safety feature adds a grace period (7 days on GitLab.com) before deleted groups and projects are permanently removed. This feature allows recovery from accidental deletions without complex recovery operations.
By making data safety a core feature, GitLab can help better protect your work against data loss events.
Delayed project deletion is now available for projects in user namespaces (personal projects). Previously, this safeguard against accidental data loss was only available for group namespaces. When you delete a project in your user namespace, it will now enter a “pending deletion” state for the duration configured in your instance settings (7 days on GitLab.com), rather than being immediately deleted. This creates a recovery window during which you can restore the project if needed.
We hope this enhancement provides greater peace of mind when managing your personal projects in GitLab.
active parameter for Groups and Projects REST APIsWe’ve added a new active parameter to our Groups and Projects REST APIs that simplifies filtering groups based on their status. When set to true, only non-archived groups or projects not marked for deletion are returned. When set to false, only archived groups or projects marked for deletion are returned. If the parameter is undefined, no filtering is applied. This enhancement helps you efficiently manage your workflows by targeting specific statuses through simple API calls.
Thank you @dagaranupam for adding this parameter to the Projects API.
We have added API rate limits for projects, groups, and users to improve platform stability and performance for all users. These changes are in response to increased API traffic that has been affecting our services.
The limits have been carefully set based on average usage patterns and should provide sufficient capacity for most use cases. If you exceed these limits, you’ll receive a “429 Too Many Requests” response.
For complete details about specific rate limits and implementation information, please read the related blog post.
You can now choose to run Application Security Testing (AST) scanners in merge request (MR) pipelines. To minimize the impact to your pipelines, this is as an opt-in behavior you can control.
Previously, the default behavior depended on whether you used the Stable or Latest CI/CD template edition to enable a scanner:
Now, a new option, AST_ENABLE_MR_PIPELINES, allows you to control whether to run jobs in MR pipelines.
The default behavior for both Stable and Latest templates remains the same. Specifically:
AST_ENABLE_MR_PIPELINES: "true" to use MR pipelines instead when an MR is open.AST_ENABLE_MR_PIPELINES: "false" to use branch pipelines instead.This improvement affects all security scanning templates except for API Discovery (API-Discovery.gitlab-ci.yml), which currently defaults to MR pipelines.
We also changed the API Discovery template to align with other Stable templates in GitLab 18.0 and use branch pipeline by default.
In the compliance projects report, you can view the compliance frameworks applied to projects within a group or subgroup.
However, the report lacked the ability to show whether a project is archived or not, which could be useful information for managing compliance across active and archived projects.
As such, we’ve added an indicator to show whether a project is archived. This will provide you with better visibility and context when reviewing compliance frameworks across both active and archived projects.
This feature includes:
You can now create a workspace directly from a merge request with the new Open in Workspace option. This feature automatically configures a workspace with the merge request’s branch and context, allowing you to:
Previously, when working on code files, you had no visibility into who else might be modifying the same file in other branches. This lack of awareness led to merge conflicts, duplicated work, and inefficient collaboration.
Now you can easily identify all open merge requests that modify the file you’re viewing in the repository. This feature helps you:
A badge displays the number of open merge requests modifying the file, and hovering over it reveals a popover with the list of these merge requests.
You can now create GitLab workspaces in a shared Kubernetes namespace. This removes the need to create a new namespace for every workspace and eliminates the requirement to give elevated ClusterRole permission to the agent. With this feature, you can more easily adopt workspaces in secure or restricted environments, offering a simpler path to scale.
To enable shared namespaces, set the shared_namespace field in your agent configuration file to
specify the Kubernetes namespace you want to use for all workspaces.
Thank you to the half dozen community contributors who helped build this feature through GitLab’s Co-Create program!
You can use the dashboard for Kubernetes to monitor your deployed applications. Until now, pods with container errors like CrashLoopBackOff or ImagePullBackOff were displayed with a “Pending” or “Running” status, which makes it difficult to identify problematic deployments without using kubectl.
In GitLab 18.0, error states in the UI show a specific container’s status, similar to the kubectl output. Now, you can quickly identify and troubleshoot failing pods without leaving the GitLab interface.
In merge request approval policies, this new enhancement to license approval policies gives legal and compliance teams more control over which packages can use specific licenses. You can now create exceptions for pre-approved packages, even when they use licenses that would normally be blocked by your organization’s policies.
Previously, in license approval policies, if you blocked a license like AGPL-3.0, it was blocked for all packages across your organization. This created challenges when:
With this release, you can maintain strict license governance while allowing necessary exceptions, significantly reducing approval bottlenecks and manual reviews. For example, you can:
To add exceptions, follow this workflow when you create or edit a license approval policy:
pkg:npm/@angular/animation@12.3.1).The policy then enforces your license rules while respecting the defined exceptions, giving you granular control over license compliance across your organization.
Administrators can now choose if the maximum length of a user session is computed from the initial sign-in or from the last activity. Users are notified that the session is ending, but cannot prevent the session from expiring or extend the session. This feature is disabled by default.
Thank you John Parent for your contribution!
We’ve made significant improvements to GitLab Query Language (GLQL) views. These improvements include support for:
>= and <= operators for all date typesWe welcome your feedback on this enhancement, and on GLQL views in general, in issue 509791.
GitLab provides templates for popular static site generators. We’ve taken a deep dive into available templates using a scoring framework, and refined the list to include only the most popular templates.
Refining templates available for GitLab Pages streamlines the website creation process. Use templates to launch professional-looking sites with minimal technical expertise. Enhanced templates also provide modern, responsive designs, eliminating the need for custom development work.
Previously, you had to configure the integration to create Jira issues from vulnerabilities from the Project settings page.
You can now configure this integration from the project integrations API, which allows you to automate the setup.
Previously, when a resolved vulnerability was redetected and changed status, the vulnerability details did not provide information to indicate when and why the status change occurred.
GitLab now adds a system note to the vulnerability history when resolved vulnerabilities change status because they appeared in a new scan. This additional information helps users understand why vulnerabilities have changed status.
With this release you can now bulk add vulnerabilities to new or existing GitLab issues from the vulnerability report. You may now associate multiple issues and vulnerabilities together. Additionally, related vulnerabilities are now listed within the issue page.
You can now remove the ability to invite members to groups or projects.
This feature helps organizations maintain strict control over membership access.
LDAP users can now authenticate requests with their GitLab username. Previously, if the GitLab username didn’t match their LDAP username, GitLab returned an authentication error. This change helps users maintain separate naming conventions in GitLab and LDAP systems without disrupting approval workflows.
GitLab now automatically detects and supports both SHA1 and SHA256 certificate fingerprints for Group SAML authentication. This maintains backward compatibility with existing SHA1 fingerprints while adding support for more secure SHA256 fingerprints. This upgrade is essential to prepare for the upcoming ruby-saml 2.x release that will make SHA256 the default.
Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.
With our new fine-grained permissions for job tokens beta feature, you can now precisely control which specific resources a job token can access within a project. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for each job to complete its tasks.
We’re actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.
You can create custom roles with the Manage protected environments permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Maintainer or Owner role.
The redesigned CI/CD analytics view transforms how your development teams analyze, monitor, and optimize pipeline performance and reliability. Developers can access intuitive visualizations in the GitLab UI that reveal performance trends and reliability metrics. Embedding these insights in your project repository eliminates context-switching that disrupts developer flow. Teams can identify and address pipeline bottlenecks that drain productivity. This enhancement leads to faster development cycles, improved collaboration, and data-driven confidence to optimize your CI/CD workflows in GitLab.
We’re also releasing GitLab Runner 18.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.
ConfigurationError and ExitCodeInvalidConfiguration to the GitLab Runner build error classificationsThe list of all changes is in the GitLab Runner CHANGELOG.
On April 17, 2025, GitLab 17.11 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
For 17.11, we’re delighted to recognize Heidi Berry as our Notable Contributor!
Heidi has been a standout contributor to the GitLab Terraform Provider and client-go projects. Over the past several releases, she has consistently delivered highly requested features including the ability to use custom roles with Group SAML links, support for setting branch protection defaults for group, and automatic token rotation for service account tokens.
Beyond feature development, Heidi has been instrumental in maintenance activities - helping with issue backlog refinement, updating older tests for improved readability, and enhancing documentation with better examples. Her contributions to client-go are particularly valuable as this library powers many downstream projects that both customers and GitLab use to interact with GitLab, including the Terraform provider and glab.
“If you have ever wanted to try your hand at open source contributing, try out client-go and terraform-provider-GitLab,” says Heidi. “They have great documentation to get you started, and supportive maintainers ready to help. I have enjoyed using these projects to learn the go language in a practical way.”
Heidi was nominated by another community contributor, Patrick Rice, who is an Enterprise Architect at Kingland and member of the GitLab community Core Team. Patrick says: “With over 100 merged contributions so far across the 17 release cycle and more issue comments, Heidi has been a great help to GitLab and Terraform. Thank you so much for your contributions!”
“Heidi does phenomenal work,” said Timo Furrer, Senior Backend Engineer in Deploy::Environments at GitLab. “She regularly goes the extra mile and implements the necessary SDK code in client-go. Heidi not only contributes a lot of code, but also helps with issue triaging. It’s an immense help and it’s the reason community-driven projects like these can sustain.”
Heidi is a Lead Software Engineer at The Co-operative Group, where she helps make developer experience efficient, secure and as effortless as possible.
Thank you, Heidi, for your tremendous contributions to GitLab!
Previously, compliance frameworks in GitLab could be created as a label to identify that your project has certain compliance requirements or needs additional oversight. This label could then be used as a scoping mechanism to ensure that security policies could be enforced on all projects within a group.
In this release, we are introducing a new way for compliance managers to get more in-depth compliance monitoring in GitLab through ‘requirements’.
With requirements, as part of a custom compliance framework, you can define specific requirements from a number of different compliance standards, laws, and regulations that must be followed as an organization.
We are also expanding the number of compliance controls (previously known as compliance checks) that we offer from five to over 50! These 50 out-of-the-box (OOTB) controls can be mapped to the compliance framework requirements.
These controls check particular project, security, and merge request settings across your GitLab instance to help you meet requirements under a number of different compliance standards, laws, and regulations such as SOC2, NIST, ISO 27001, and the GitLab CIS Benchmark.
Adherence to these controls is reflected in standard adherence report, which is redesigned to take into account requirements and the mapping of controls to those requirements.
In addition to expanding our OOTB controls, we now allow users to map requirements to external controls, which can be for items, programs, or systems that exist outside the GitLab platform. These mappings allow you to use the GitLab compliance centre as the single source of truth when it comes to your compliance monitoring and audit evidence needs.
We’re thrilled to announce the beta release of the GitLab Eclipse plugin, now available in the Eclipse Marketplace. This powerful new plugin extends GitLab’s Duo features directly into your Eclipse IDE, giving you seamless access to Duo Chat and AI-powered code suggestions.
As the plugin is currently in beta, we’re actively improving features, including expanding authentication options, and refining the final user experience. Your feedback is invaluable. Please share your thoughts to help us make the GitLab Eclipse plugin even better by adding your feedback in issue 162.
You can now use more GitLab Duo features with GitLab Duo Self-Hosted in your GitLab Self-Managed instance. The following features are available in beta:
Code Review Summary is also available on GitLab Duo Self-Hosted as an experiment.
We’re thrilled to announce the launch of the extension marketplace in the Web IDE for self-managed users. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience.
By default, the GitLab instance is configured to use the Open VSX extension registry. To activate this, follow the enable with default extension registry steps.
If you want to use your own or custom registry, you also have the option to connect a custom extension registry. This provides you with more flexibility to manage available extensions.
After enabling the extension marketplace, individual users must still opt in to use it. They can do this by going to the Integrations section in their Preferences settings.
It’s important to note that some extensions require a local runtime environment and are not compatible with the web-only version. Despite this, you can still choose from thousands of available extensions to boost your productivity and customize your workflow.
We’re excited to announce general availability for GitLab Duo with Amazon Q, a joint offering that brings together the comprehensive GitLab AI-powered DevSecOps platform with autonomous Amazon Q AI agents in a single, integrated solution. GitLab Duo with Amazon Q integrates AI agents directly into development workflows, allowing developers to accelerate key tasks without switching tools. Acting as intelligent assistants within the GitLab DevSecOps platform, these agents automate time-consuming processes like code generation, testing, reviews, and Java modernization, helping teams focus on innovation while maintaining security and quality standards.
GitLab Duo with Amazon Q provides major benefits for development teams:
/q dev, which will convert an issue description directly into merge-ready code in minutes./q transform to automate the entire Java modernization process./q review to get instant, intelligent feedback on code quality and security directly in merge requests./q test to generate comprehensive unit tests that understand your application logic.Container registries are critical infrastructure for modern DevSecOps teams. Until now, GitLab users with the Developer role or higher could push and delete any container tag in their projects, creating risks of accidental or unauthorized changes to production-critical container images.
With protected container tags, you now have fine-grained control over who can push or delete specific container tags. You can:
latest, semantic versions (for example, v1.0.0), or stable release tags (for example, main-stable).This feature requires the next-generation container registry, which is already enabled by default on GitLab.com. For GitLab Self-Managed instance, you’ll need to enable the metadata database to use protected container tags.
We’re thrilled to introduce support for protected Maven packages to enhance the security and stability of your GitLab package registry. Accidental modification of packages can disrupt the entire development process. With protected packages, you can safeguard your most important dependencies against unintended changes.
In GitLab 17.11, you can now protect Maven packages by creating protection rules. If a package matches a protection rule, only specified users can push new versions of the package. Package protection rules prevent accidental overwrites, improve compliance with regulatory requirements, and reduce the need for manual oversight.
Protected packages support for Maven and other package formats are all community contributions from gerardo-navarro and the Siemens crew. Thank you, Gerardo, and the rest of the crew from Siemens for their many contributions to GitLab! If you want to learn more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.
With this release, you can configure text, number, single-select, and multi-select custom fields for issues, epics, tasks, objectives, and key results. While labels have been the primary way to categorize work items up to this point, custom fields provide a more user-friendly approach for adding structured metadata to your planning artifacts.
Custom fields are configured in your top-level group and cascade to all subgroups and projects. You can map fields to one or more work item types and filter by custom field values in the issues and epics lists.
As of this release, the new issue look is generally available and replaces the legacy issue experience. Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:
/set_parent, /remove_parent, /add_child, and /remove_child.You now can use a dedicated space to create and manage service accounts in the GitLab UI. This interface allows you to create, monitor, and control automated access to your GitLab resources. Previously, this functionality was only available in the API.
You can now automatically assign a Duo Pro or Duo Enterprise seat to users with SAML Group Sync. As long as the GitLab group has available Duo Pro or Duo Enterprise seats, any user mapped from the identity provider is automatically assigned a seat. This reduces the effort to manage seat assignments.
CI/CD variables are essential for dynamic CI/CD workflows, and are used for many things, including as environment variables, context variables, tool configuration, and matrix variables. But developers sometimes rely on CI/CD variables to inject pipeline variables into pipelines to manually modify pipeline behavior, which have some risks due to the higher precedence of pipeline variables.
In GitLab 17.11 and later, you can now use inputs to safely modify pipeline behavior instead of using pipeline variables, including in scheduled pipelines, downstream pipelines, triggered pipelines, and other cases. Inputs provide developers with a more structured and flexible solution for injecting dynamic content at CI/CD job runtime. After you switch to inputs, you can completely disable access to pipeline variables.
We’d greatly appreciate it if you could try it out and share your feedback through this dedicated issue.
GitLab Duo Chat now uses Anthropic Claude Sonnet 3.7 as the base model, replacing Claude 3.5 Sonnet for answering most questions.
Claude 3.7 Sonnet has strongly improved coding and reasoning capabilities, making it even better at explaining code, generating code, processing text data, and answering complex DevSecOps questions. You’ll notice more detailed and accurate Chat responses in these areas.
This upgrade applies to all Chat features, and ensures a consistent and improved experience across the entire Chat interface.
On GitLab Duo Self-Hosted, you can now use files open in tabs in your IDE as context when using Code Suggestions.
On GitLab Duo Self-Hosted, you can now select and configure individual supported models for each GitLab Duo feature and sub-feature on your GitLab Self-Managed instance.
To leave feedback, go to issue 524175.
Llama 3 models are now generally available with GitLab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.
To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.
Multiple conversations with GitLab Duo Chat is now available in GitLab Self-Managed instances in the web UI. You can create new conversations, browse your conversation history, and switch between conversations without losing context.
For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time. On GitLab Self-Managed, administrators can reduce how long conversations are retained for.
Share your experience with us in issue 526013.
With this release, webhooks that return 4xx errors are now automatically re-enabled. All errors (4xx, 5xx, or server errors) are treated the same way, allowing for more predictable behavior and easier troubleshooting. This change was announced in this blog post.
Failing webhooks are temporarily disabled for one minute, extending to a maximum of 24 hours. After a webhook fails 40 consecutive times, it now becomes permanently disabled.
Webhooks that were permanently disabled in GitLab 17.10 and earlier underwent a data migration.
auto_disabling_webhooks``ops flag is enabled.Thanks to Phawin for this community contribution!
Previously, ghost user contributions would create placeholder references that required manual reassignment, creating extra work during migrations. Now, importers using new contributions and membership mapping functionality, migration by direct transfer, GitHub, Bitbucket Server and Gitea importers, handle ghost user contributions more intelligently. When importing content to GitLab, contributions previously made by the ghost user on the source instance are now automatically mapped to the ghost user on the destination instance.
This enhancement eliminates the creation of unnecessary placeholder users for ghost user contributions, reducing clutter in user mapping interface and simplifying the migration process.
In this milestone, we’ve added SAML verification checks to contribution reassignment when importing to GitLab.com. These checks prevent reassignment errors in groups where SAML SSO is enabled.
If you import to GitLab.com and use SAML SSO for GitLab.com groups, all users must link their SAML identity to their GitLab.com account before you can reassign contributions and memberships. When you reassign contributions to users who have not verified their SAML identity, you’ll receive error messages. These messages explain the steps to take to help ensure your group memberships are attributed correctly.
Previously, placeholder users created during imports appeared mixed with regular users without clear distinction in the Admin area Users page.
With this release, administrators can now filter for placeholder accounts from the search box
in the Users page in the Admin area. To do this, select Type in the dropdown list,
then choose Placeholder.
For imports to GitLab.com, placeholder users are limited per top-level group. These limits depend on your GitLab license and number of seats. With this release, it’s possible to check your placeholder user usage and limits for a top-level group in the UI.
To view your current usage and limits:
We are introducing a new look and feel for the replicables view in Geo. The new experience better aligns with the rest of GitLab and provides a more streamlined and less cluttered interface to review the synchronization and verification status of Geo secondary sites. In addition, there is now a click-through detailed view for each replicable item, providing information such as the primary and secondary checksums, error details, and much more. This information will make troubleshooting Geo synchronization issues much easier.
In GitLab 18.0, the minimum-supported version of PostgreSQL will be version 16. To prepare for this change, on instances that don’t use PostgreSQL Cluster, upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to version 16.
If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 16 to be able to upgrade to GitLab 18.0.
In GitLab 18.0, we plan to enable event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption.
Starting in GitLab 17.11, you will have the ability to opt out of event data collection before it starts, effectively allowing you to choose participation in advance. For more information and details on how to opt-out please see our documentation.
GitLab secret detection has received significant updates, including 17 new secret push protection rules and 12 new pipeline secret detection rules. Some existing rules have also been updated to improve quality and reduce false positives. For details, see v0.9.0 in the change log.
The Composition Analysis team has released beta support for static reachability for Python. This beta release focuses on enhancing stability, observability, and provides a better user experience via easier configuration.
Static reachability enriches software composition analysis (SCA) results. Powered by GitLab Advanced SAST, static reachability scans project source code to identify which open source dependencies are in use.
You can use the data produced by static reachability as part of your triage and remediation decision making. Static reachability data can also be used with CVSS and EPSS scores, as well as KEV indicators to provide a more focused view of your vulnerabilities.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team please see this feedback issue.
The Dynamic Analysis team has introduced a check for CWE-79. This work allows our DAST scanner to check for reflected XSS attacks.
Checking for Reflective XSS is on by default. To turn off this check, in you configuration, set DAST_FF_XSS_ATTACK: false.
If you have questions or feedback, see issue 525861.
GitLab Duo Code Suggestions can now use imported files in your IDE to enrich and improve the quality of suggestions. Imported files provide additional context about your project. Imported file context is supported for JavaScript and TypeScript files.
In the past, you couldn’t assign new compliance frameworks to projects without navigating to the Projects tab in the compliance center after creating the compliance framework. This situation created unnecessary friction to creating new compliance frameworks in your groups.
In GitLab 17.11, when creating a compliance framework, we introduced a new step that provides the option of assigning multiple projects to the compliance framework before it is created.
This new feature:
This release adds full support for Kubernetes version 1.32, released in December 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
You can now configure SAML single sign-on (SSO) for your GitLab Dedicated instance for up to ten identity providers (IdPs).
All SAML configuration options available for GitLab Dedicated instances can be configured for each individual IdP.
If you had previously configured multiple IdPs, you can now view and edit all existing SAML configurations directly in Switchboard.
We’re excited to announce UI support for Docker Hub authentication in the GitLab Dependency Proxy. This feature was initially introduced in GitLab 17.10 with GraphQL API support only, and now includes a user interface for easier configuration.
With this enhancement, you can now configure Docker Hub authentication directly from your group settings page, helping you:
This streamlined approach makes it easier to maintain uninterrupted access to Docker Hub images in your CI/CD pipelines without using the GraphQL API.
You can now set work in progress limits by weight in addition to issue count, giving you more flexibility in managing your team’s workload.
Control the flow of work based on the complexity or effort of each task, rather than just the number of issues. Teams that use issue weights to represent effort can now ensure they don’t overcommit by limiting the total weight of issues in a given board list.
Use this feature to optimize your team’s productivity and create a more balanced workflow that accounts for varying task complexity.
The custom wiki sidebar now features improved styling with reduced heading sizes and better left-padding for lists. These ergonomic enhancements improve the readability of custom navigation created through the _sidebar wiki page.
Custom sidebars help teams organize their wiki content in a way that makes sense for their unique knowledge base structure. With this styling update, the sidebar is now easier to scan, creating a clearer visual hierarchy that helps team members find relevant information more quickly.
GLQL views now support displaying the last comment on an issue or merge request as a column. By including lastComment as a field in your GLQL query, you can see the most recent updates without leaving your current context.
Previously, you had to open each issue or merge request individually to view the last comment, which was time consuming and made it difficult to get a quick overview of progress. This improvement helps teams maintain momentum by providing at-a-glance visibility into ongoing conversations and status updates.
We welcome your feedback on this enhancement and GLQL views in general on our feedback issue.
GitLab provides templates for the most popular Static Site Generators (SSGs), and you can now create a GitLab Pages site using Nuxt, a powerful framework built on Vue.js. Nuxt is particularly valuable for teams looking to build modern, performant web applications with less configuration overhead.
This addition expands your options for quickly launching a Pages site with built-in CI/CD pipelines and a modern development experience, without spending time on initial setup and configuration.
Many organizations now require a software bill of materials (SBOM) to meet regulatory requirements and help further increase the security of the software supply chain. Previously, you could only export your dependency list as a JSON or CSV file from GitLab. Now, GitLab can generate your SBOM by exporting your dependency list in the widely-adopted CycloneDX format.
To download an SBOM directly as a CycloneDX file, in the dependency list, select Export > Export as CycloneDX (JSON).
Previously, when exporting the dependency list or the vulnerability report, you had to remain on the page until the export completed before you could download the report.
Now, you are notified by email with a download link when the dependency list or vulnerability report export is complete.
Previously, you could not export a dependency list from GitLab as CSV file. Now, when you download a dependency list, you can select the new CSV option to export the list in this format.
Previously, the tool search filter in the vulnerability report allowed you to filter results based on a single group of tools that included the type of scanner (like ESLint or Gemnasium) and the type of report (like SAST or container scanning).
To help you find the appropriate tools more easily, we’ve replaced the tool filter with the scanner filter and the report type filter. You can now filter your search based on each of these types of tools separately.
source value for CI/CD jobsGitLab 17.11 introduces a new feature that allows users to verify the origin of build artifacts by tracking the source attribute of CI/CD jobs. This enhancement is particularly valuable for security and compliance workflows. For example, organizations can implement software supply chain security measures or require verifiable evidence of security scans for compliance purposes.
Jobs in GitLab now store and display a source value that identifies whether they originated from:
You can access the source attribute on the Build > Jobs page with a new filter option, using the Jobs API, or through the ID token claims for artifact verification.
With this new feature, you can now:
Security and compliance teams can leverage this feature to:
source field in the Jobs API.job_source: Identifies the job’s origin.job_policy_ref_uri: Points to the policy file (for policy-defined jobs).job_policy_ref_sha: Contains the git commit SHA of the policy.There are now additional sorting options for access tokens in the UI and API. These sorting options complement GitLab’s existing token management capabilities, giving you more control over your access token inventory, and helping you better maintain access token security. The new sorting options include:
The token management interface for service accounts now includes a helpful statistics dashboard that provides at-a-glance information about your token inventory. This information can help you assess the state of your tokens and identify tokens that require attention. The statistics dashboard includes four key metrics:
You can now quickly identify failed jobs in the pipeline graph with new visual indicators. Failed job groups are highlighted in the pipeline graph, and failed jobs are grouped at the top of each stage. This improved visualization helps you troubleshoot pipeline failures without having to search through complex pipeline structures.
CI/CD jobs can occasionally get stuck in the ‘canceling’ state, blocking deployments or access to shared resources.
Users with the Maintainer role can now force-cancel these stuck jobs directly from the job logs page, ensuring problematic jobs can be properly terminated.
You can now manage runners more efficiently in your projects. Runners are displayed in a single-column layout and organized in their own lists instead of the previous two-column view.
This improved organization makes it simpler to find and manage runners, with new features including a list of assigned projects, runner managers, and jobs that a runner has run. For information about additional runner management improvements planned for GitLab 18.0, see issue 33803.
We’re also releasing GitLab Runner 17.11 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.
FF_DISABLE_UMASK_FOR_KUBERNETES_EXECUTOR flag doesn’t disable the umask commandThe list of all changes is in the GitLab Runner CHANGELOG.
On March 20, 2025, GitLab 17.10 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Alexey Butkeev is a valued community contributor whose contributions enhance our global reach and user experience. His impactful localization and translation contributions exemplify our Diversity, Inclusion, and Belonging value.
“I’m honored to be selected as the 17.10 MVP and to contribute to making GitLab more accessible and inclusive,” says Alexey. “Localization is a team effort, and I’m grateful to be part of such a supportive community.”
In addition to his code contributions, Alexey took the initiative to find, document, and fix translation errors via GitLab and Crowdin. His thorough research and problem solving make him our 17.10 MVP.
Alexey was nominated by Oleksandr Pysaryuk, Senior Manager, Globalization Technology at GitLab, and supported by Daniel Sullivan, Director of Globalization & Localization at GitLab. “We appreciate your work and support here at GitLab so much,” says Daniel. “Thank you for your part in helping us become a more globally supported company!”
Thank you Alexey for making GitLab more inclusive and transparent!
Code review is an essential activity of software development. It ensures that contributions to a project maintain and improve code quality and security, and is an avenue of mentorship and feedback for engineers. It’s also one of the most time-consuming activities in the software development process.
Duo Code Review is the next evolution of the code review process.
Duo Code Review can accelerate your development process. When it performs an initial review on your merge request, it can help identify potential bugs and suggest further improvements - some of which you can apply directly from your browser. Use it to iterate on and improve your changes before you add another human to the loop.
Try it out:
@GitLabDuo as a reviewer to your merge request.@GitLabDuo in a comment.You can track future progress for Duo Code Review in epic 13008 and related child epics. Feedback can be provided in issue 517386.
You can now use GitLab Duo Root Cause Analysis on GitLab Duo Self-Hosted. This feature is in beta for GitLab Self-Managed instances using GitLab Duo Self-Hosted, with support for Mistral, Anthropic, and OpenAI GPT model families.
With Root Cause Analysis on GitLab Duo Self-Hosted, you can troubleshoot failed jobs in CI/CD pipelines faster without compromising data sovereignty. Root Cause Analysis analyzes the failed job log, quickly determines the root cause of the job failure, and suggests a fix for you.
Note: This feature currently has limited functionality, and full functionality is planned for 17.11. Additional information is available in troubleshooting documentation and in issue 527128.
Please leave feedback on Root Cause Analysis for GitLab Duo Self-Hosted in issue 523912.
GitLab Dedicated customers can now select from an expanded list of AWS regions when choosing where to host their failover instance for disaster recovery.
Expanding failover support to additional regions enables GitLab Dedicated customers to fully use the disaster recovery functionality of GitLab Dedicated regardless of which AWS region they need to use to satisfy their data residency needs.
These newly available regions are only available for hosting failover instances as they do not fully support certain AWS features that GitLab Dedicated relies on.
Tracking and understanding work in progress across GitLab previously required navigating multiple locations, reducing team efficiency and consuming valuable time.
This release introduces GitLab Query Language (GLQL) views Beta so you can create dynamic, real-time work tracking directly in your existing workflows.
GLQL views embed live data queries in Markdown code blocks throughout Wiki pages, epic descriptions, issue comments, and merge requests.
Previously available as an experiment, GLQL views now enter beta with support for sophisticated filtering using logical expressions and operators across key fields, including assignee, author, label, and milestone. You can customize your view’s presentation as tables or lists, control which fields appear, and set result limits to create focused, actionable insights for your team.
Teams can now maintain context while accessing the information they need, creating shared understanding, and improving collaboration — all without leaving their current workflow.
We welcome your feedback on GLQL views as we continue to enhance this feature.
GitLab Flavored Markdown has been enhanced with several powerful improvements:
+s to URLs).+ to URLs).include syntax.These improvements make GitLab Flavored Markdown more powerful for teams creating and maintaining documentation while offering greater flexibility in how content is presented and organized.
We are excited to introduce the Projects by DORA metric panel, a new addition to the Value Streams Dashboard. This table lists all projects in the top-level group, with breakdown into the four DORA metrics. Managers can use this table to identify high, medium, and low-performing projects. This information can also help make data-driven decisions, allocate resources effectively, and focus on initiatives that enhance software delivery speed, stability, and reliability.
The DORA metrics are available out-of-the-box in GitLab, and now together with the DORA Performers score panel executives have a complete view into their organization’s DevOps health top to bottom.
Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:
/set_parent, /remove_parent, /add_child, and /remove_child.You can now streamline your workflow and maintain consistency across your projects with description templates for work items (epics, tasks, objectives, and key results).
This powerful addition allows you to create standardized templates, saving you time and ensuring all crucial information is included every time you create a new work item.
When triaging vulnerabilities, you need the flexibility to adjust severity levels based on your organization’s unique security context and risk tolerance. Until now, you had to rely on the default severity levels assigned by security scanners, which might not accurately reflect the risk level for your specific environment.
Now you can manually change the severity of specific vulnerability occurrences to better align with your organization’s security needs. This allows you to:
All severity changes are tracked in the vulnerability history and audit events and can only be overridden by your team members who have at least the Maintainer role for the project, or a custom role with the admin_vulnerability permission. This feature gives security teams more flexibility and control over vulnerability prioritization.
In the GitLab UI, you can now resize the Duo Chat drawer. This makes it easier to view code outputs, or keep Chat open whilst working with GitLab in the background.
Maintaining context across different topics in GitLab Duo Chat is now easier with multiple conversations. You can create new conversations, browse your conversation history, and switch between conversations.
Previously, starting a new conversation meant losing the context of your existing chat. Now, you can manage multiple conversations on different topics. Each conversation maintains its own context, so for example, you can ask follow-up questions about code explanations in one conversation, whilst preparing a work-plan in another conversation.
When you need to revisit previous discussions, select the new chat history icon to see all your recent conversations. Conversations are automatically organized by most recent activity, making it easy to pick up where you left off.
For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time.
This feature is currently available only on GitLab.com in the web UI. It is not available in GitLab Self-Managed instances, nor in IDE integrations.
Share your experience with us in issue 526013.
On GitLab Duo Self-Hosted, you can now select individual supported models for each GitLab Duo Chat sub-feature on your self-managed instance. Model selection and configuration for Chat sub-features is now in beta.
To leave feedback, go to issue 524175.
You can now use the AI Impact Dashboard with GitLab Duo Self-Hosted Code Suggestions on your self-managed instance to help you understand the impact of GitLab Duo on your productivity. The AI Impact Dashboard is in beta with GitLab Duo Self-Hosted, and you can use this feature with your self-managed instance and Visual Studio Code, Microsoft Visual Studio, JetBrains, and Neovim IDEs.
Use the AI Impact Dashboard to compare AI usage trends with metrics like lead time, cycle time, DORA, and vulnerabilities. This allows you to measure how much time is saved in your end-to-end workstream using GitLab Duo Self-Hosted, whilst staying focused on business outcomes rather than developer activity.
Please leave feedback on the AI Impact Dashboard in issue 456105.
You can now use select Meta Llama 3 models with GitLab Duo Self-Hosted. These models are in beta for GitLab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.
Please leave feedback on using these models with GitLab Duo Self-Hosted in issue 523912.
Previously, when you imported groups or projects, you could not see when placeholder users were created. With this release, we’ve added timestamps so you can track the progress of your migration and troubleshoot any issues as they occur.
You can now efficiently manage your To-Do List with our improved bulk editing feature. Select multiple to-do items and mark them as done or snooze them in one go, giving you more control over your tasks and helping you stay organized with less effort.
You can now snooze notifications in your To-Do List, allowing you to temporarily hide items and focus on what’s most important right now. Whether you need an hour to concentrate or want to revisit a task tomorrow, you’ll have fine-grained control over when notifications reappear, helping you manage your workflow more effectively.
With this release, user contribution mapping now supports bulk reassignment by using a CSV file. If you have a large user base with many placeholder users, group members with the Owner role can:
This method eliminates tedious manual reassignment through the UI. To further streamline large-scale migrations, API support for CSV-based reassignment is now also available.
We’re excited to announce significant improvements to the project overview in Your Work, designed to streamline how you discover and access your projects. This update introduces a more intuitive tab-based navigation system that better reflects how users interact with their projects.
Further, if you have the appropriate permissions, you can now edit or delete a project directly from the Your Work projects overview. These changes reflect our commitment to creating a more efficient and user-friendly GitLab experience. The new layout helps you focus on the projects that matter most to your work, reducing the time spent navigating between different project categories.
We value your feedback on this update! Join the discussion in epic 16662 to share your experience with the new navigation system.
We’ve improved the project creation permission settings to make them more clear, intuitive, and aligned with our security principles. The improved settings include:
These changes make it easier to understand and configure which roles can create projects within your groups, helping administrators enforce appropriate access controls more confidently.
Thank you @yasuk for this community contribution!
Dependency Scanning has added support for pub, the official package manager for Dart. Support for this has been added to our Dependency Scanning latest template and CI/CD component.
This addition was a community contribution from one of our users, Alexandre Laroche. The GitLab Composition Analysis team appreciates this contribution to improve our product, many thanks, Alexandre. If you are interested in learning more about contributing to GitLab please check out our Community Contribution program.
Users can set a default compliance framework in the GitLab compliance centre, which is applied to all new and imported projects that are created in that group. A default compliance framework has a default label to help users identify it.
To make it easier to set a compliance framework as default, we are introducing the ability for users to set a framework as default by using the framework dropdown list on the list frameworks page in the compliance center of a top-level group. This feature isn’t available in the compliance center of subgroups nor projects.
When browsing the history of a repository, there might be commits that aren’t relevant to otherwise meaningful changes in the project. This can happen during:
When you look through the history of a project with blame, these kinds of commits make it difficult to understand the changes that occurred. Git supports identifying these commits with a .git-blame-ignore-revs file in your project. GitLab now allows you to toggle the blame view to show or hide these specific revisions in the “Blame preferences” dropdown list, making it easier to understand the history of your project.
When teams configure a CODEOWNERS file, it’s common to include broad matching patterns for paths
and file types. These broad configurations can be problematic if your documentation, automated
build files, or other patterns don’t require a specified Code Owner.
You can now configure the CODEOWNERS file with path exclusions to ignore certain paths. This is helpful
when you want to exclude specific files, or paths from requiring a Code Owner approval.
Different Git workflows require different strategies for handling commits when merging between branches. In previous versions of GitLab, you could only set a single strategy for whether commits should be squashed when merging and how strongly that should be enforced. This setup could be error-prone or require developers to make specific choices to follow the project convention for different branch targets.
You can now configure squash settings for each protected branch through branch rules. For example, you can:
feature branch to the develop branch to keep history clean.develop branch to main branch when you want the commit history to remain intact.This flexibility ensures consistent commit history across your project while respecting the unique needs of each branch in your workflow, all without requiring manual developer intervention.
Previously, access token expiry notification emails were only sent to direct members of the group and project in which the token was expiring. Now, these notifications are also sent to inherited group and project members, if the setting is enabled. This wider distribution makes it easier to manage the token before expiry.
needs statements in pipeline execution policies for complianceTo strengthen your control over pipeline execution, jobs enforced in the .pipeline-policy-pre reserved stage are now required to complete before jobs in subsequent stages can begin, regardless of whether the job defines any needs statements. Previously, jobs defined in the .pipeline-policy-pre stage and jobs in subsequent pipelines with a needs statement both started as soon as the pipeline executed. With this enhancement, jobs in subsequent stages must wait for the .pipeline-policy-pre to complete before starting any other jobs without dependencies, helping you enforce ordered execution and ensuring compliance within the security policies.
Our customers rely on reserved stages to enforce compliance and security checks before developer jobs run. A common use case is to enforce a security or compliance check that fails the entire pipeline if the check does not pass. Allowing jobs to run out of order could bypass this enforcement and weaken policy intent. This improvement provides you with a more consistent approach to compliance enforcement.
To inject jobs at the beginning of the pipeline without overriding needs behavior, configure the jobs to use a custom stage with the new custom stages feature that we introduced in 17.9.
You can now authenticate to private GitLab Pages sites programmatically using access tokens, making it easier to automate interactions with your Pages content. Previously, accessing restricted Pages sites required interactive authentication through the GitLab UI.
This powerful enhancement increases productivity while maintaining security, giving developers more flexibility in how they interact with and distribute private Pages content.
The AI comparison metrics panel on the AI Impact Dashboard now provides month-over-month (MoM) tracking for GitLab Duo Code Suggestions acceptance rate and GitLab Duo Chat usage (MoM%). These new trend-based insights complement the existing Duo Code Suggestions and Duo Chat tiles, which provide a 30-day snapshot of these metrics. With these additional metrics, managers can better measure the AI impact on their software development processes and identify patterns, by comparing Code Suggestions acceptance rate and Duo Chat usage with other SDLC metrics over time.
The GitLab Dependency Proxy for container images now supports authentication with Docker Hub, helping you avoid pipeline failures due to rate limits and giving you access to private images.
Starting April 1, 2025, Docker Hub will enforce stricter pull limits (100 per 6-hour window per IPv4 address or IPv6 /64 subnet) for unauthenticated users. Without authentication, your pipelines might fail once these limits are reached.
With this release, you can configure Docker Hub authentication through the GraphQL API using your Docker Hub credentials, personal access token, or organization access tokens. Support for UI configuration will be available in GitLab 17.11.
Package registry operations are now logged as audit events so teams can track when packages are published or deleted to meet compliance requirements.
Before this release, there was no built-in way to track who published or made changes to packages. Teams had to create their own tracking systems or manually document package changes to maintain logs of these activities. Now, each audit event shows who made a change, when it happened, how they were authenticated, and exactly what changed in the package.
Audit events for projects are stored either in a group namespace or the project itself for individual project Owners. Groups can turn off audit events to manage storage needs.
You can now sort personal, project, and group access tokens in the Credentials Inventory by owner, created date, and last used date. This helps you to locate and identify your access tokens more quickly. Thank you Chaitanya Sonwane for your contribution!
GitLab administrators can now use a unified API to identify and revoke tokens. Previously, administrators had to use endpoints related to the specific type of token. This API allows revocation regardless of the type. For a list of supported token types, see the Token information API.
Thank you Nicholas Wittstruck and the team from Siemens for your contribution!
When using GitLab as an OpenID Connect (OIDC) provider, you can now configure the duration of ID tokens with the id_token_expiration attribute. Previously, ID tokens had a fixed expiration time of 120 seconds.
Thank you Henry Sachs for your contribution!
You can now map the Organization and Title profile attributes from an OmniAuth identity provider (IdP) to a user’s GitLab profile. This allows the IdP to be the single source of truth for these attributes, and users can no longer change them.
You can now trigger webhook events 60 and 30 days before a project or group access token expires. Previously, these webhook events only triggered 7 days before expiry. This is an optional setting that matches the existing email notification schedule for expiring tokens.
We’re also releasing GitLab Runner 17.10 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.
gitlab-runner-helper image fails due to invalid volume specification for the `/opt/step-runner’ pathgit submodule update --remote in GitLab CI/CD returns an errorThe list of all changes is in the GitLab Runner CHANGELOG.
On February 20, 2025, GitLab 17.9 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
We’re excited to recognize Salihu Dickson as our MVP for his outstanding contributions to developing Comments on Wiki pages, a highly-requested feature that gathered over 200 positive reactions from the community!
His dedication spanned over six months, delivering an implementation of wiki top-level discussions with nearly 4,000 lines of code. Salihu also created several proof-of-concept implementations and improved the Wiki experience with additional features and bug fixes.
“Salihu has been an outstanding Community Contributor in developing Comments on Wiki pages!” shares Matthew Macfarlane, Product Manager, Plan:Knowledge at GitLab. “Salihu’s extensive knowledge of the product has allowed us to deliver this key feature more efficiently. As a Product Manager, it is a joy to work with contributors like Salihu!”
“An incredible achievement!” shares Alex Fracazo, Senior Product Designer, Plan:Knowledge at GitLab. “Salihu didn’t just build the basic functionality, but delivered a comprehensive end-to-end feature from top-level discussions on Wiki pages to error handling and test coverage.” Many members of the GitLab team showed strong appreciation for Salihu’s work, including Natalia Tepluhina, Principal Engineer, Vue.js core team member, and Vladimir Shushlin, Engineering Manager, Plan:Knowledge at GitLab, highlighting his technical skills and collaboration.
Salihu, a front-end engineer at Elixir Cloud and two-time GSoC mentor, shared - “I’d like to thank everyone who worked closely with me to make this possible. A special thank you to Himanshu Kapoor (Staff Frontend Engineer, Plan:Knowledge at GitLab) - your mentorship over the past few months has been instrumental to all the work I’ve done here, and I truly appreciate all the guidance and support you’ve provided. Bringing this feature to life was really a team effort—from the reviewers who meticulously went through hundreds of lines of code, to the backend developers like Piotr Skorupa (Backend Engineer, Plan:Knowledge at GitLab), who made this possible.” He expressed enthusiasm about collaborating with the team and “contributing to many more impactful features in the future!”
We are so grateful to Salihu for all of his contributions and to all of our open source community for contributing to GitLab!
You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for GitLab Duo Code Suggestions and Chat. This feature is now generally available on self-managed GitLab environments with applicable licensing.
With GitLab Duo Self-Hosted, you can use models hosted either on-premise or in a private cloud as the source for GitLab Duo Chat or Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock, Claude 3.5 Sonnet on AWS Bedrock, and OpenAI models on Azure OpenAI. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.
Please leave feedback in issue 512753.
You can now create multiple versions of your GitLab Pages sites simultaneously with parallel deployments. Each deployment gets a unique URL based on your configured prefix. For example, with a unique domain your site would be accessible at project-123456.gitlab.io/prefix, or without a unique domain at namespace.gitlab.io/project/prefix.
This feature is especially helpful when you need to:
Parallel deployments expire after 24 hours by default to help manage storage space, though you can customize this duration or set deployments to never expire. For automatic cleanup, parallel deployments created from merge requests are deleted when the merge request is merged or closed.
Add your project files directly to Duo Chat in VS Code and JetBrains to unlock more powerful, context-aware AI assistance.
By adding project files, Duo Chat gains deep understanding of your specific codebase, enabling it to provide highly contextual and accurate responses. This context awareness gives you more relevant code explanations, precise debugging help, and suggestions that seamlessly integrate with your existing codebase. We welcome your feedback on this new, exciting feature. Please share your thoughts in our feedback issue.
GitLab workspaces now supports building and running containers directly in your development environment. When your workspace runs on a Kubernetes cluster configured with Sysbox, you can build and run containers without additional configuration.
Introduced in GitLab 17.4 as part of our sudo access feature, this capability enables you to maintain your complete container workflow in your GitLab workspace environment.
Previously, setting up a workspace required creating a devfile.yaml configuration file. GitLab now provides you with a default file that includes common development tools. This enhancement:
Start developing and create a workspace immediately without additional setup or configuration steps.
Deploy your applications to Kubernetes with more control and automation using GitLab-managed Kubernetes resources. Previously, you had to manually configure Kubernetes resources for each environment. Now, you can use GitLab-managed Kubernetes resources to automatically provision and manage these resources.
With GitLab-managed Kubernetes resources, you can:
When your developers deploy applications, GitLab automatically creates the necessary Kubernetes resources based on the provided resource templates, streamlining your deployment process and maintaining consistency across environments.
Have you ever struggled to get an overview of your deployments within a project? You can now view recent deployment details in the environments list without having to expand each environment. For each environment, the list shows your latest successful deployment and, if different, your most recent deployment attempt.
You can now add comments directly on wiki pages, transforming your documentation into an interactive collaboration space.
Comments and threads on wiki pages help teams:
With wiki comments, teams can maintain living documentation that evolves alongside their projects through direct feedback and discussion.
To improve development workflow tracking, Value Stream Analytics (VSA) has been extended with a new event - Merge request last approved at. The merge request approval event marks the end of the review phase and the start of the final pipeline run or merge stage. For example, to calculate the total merge request review time, you can create a VSA stage with Merge request reviewer first assigned as the start event and Merge request last approved at as the end event.
With this enhancement, teams gain deeper insights into opportunities to optimize review times, which help reduce the overall cycle time of development, leading to faster software delivery.
We’ve added support for the following vulnerability risk data:
You can now efficiently prioritize risk across your dependency and container image vulnerabilities using this data. You can find the data in the Vulnerability Report and in the Vulnerability Details page.
To effectively test complex applications, security teams need flexibility when they configure DAST scans. Previously, DAST scans configured through the UI had limited configuration options, which prevented successful scanning of applications with specific security requirements. This meant you had to use pipeline-based scans even for quick security assessments.
You can now configure DAST scans through the UI with the same granular control available in pipeline-based scans. This includes:
Save these configurations as reusable profiles to maintain consistent security testing across your applications. Every configuration change is tracked with audit events, so you know when scan settings are added, edited, or removed.
This enhanced control helps you run more effective security scans while maintaining compliance using detailed audit trails. Instead of spending time managing pipeline configurations, you can quickly launch the right scan for each application to find and fix vulnerabilities faster.
In the past, if you wanted to delete older CI/CD pipelines, you could only do this through the API.
In GitLab 17.9, we have introduced a project setting that allows you to set a CI/CD pipeline expiry time. Any pipelines and related artifacts older than the defined retention period are deleted. This can help reduce the disk usage in projects that run lots of pipelines that generate large artifacts, and even improve overall performance.
Previously, a request to GitLab could only be authenticated as a single user. With composite identity, we have now made it possible to authenticate a request as a service account and a user simultaneously. AI agent use cases often require permissions to be based on the user who initiated the tasks in a system, while simultaneously showing a distinct identity that’s separate from the initiating user. A composite identity is our new identity principal, which represents an AI agent’s identity. This identity is linked with the identity of the human user who requests actions from the agent. Whenever an AI agent action attempts to access a resource, a composite identity token is used. This token belongs to a service account, and is also linked with the human user who is instructing the agent. The authorization checks that run on the token take into account both principals before granting access to a resource. Both identities need to have access to the resource, otherwise access is denied. This new functionality enhances our ability to protect resources stored in GitLab. For more information about how the composite identity for service accounts can be used, see the documentation.
Users can choose to make their user profile public or private. Administrators can now control whether users have the option to make profiles private across their GitLab instance. In the Admin Area, “Allow users to make their profiles private” controls this setting. This setting is enabled by default, allowing users to choose private profiles.
Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it’s possible to manage these integrations with the REST API too.
Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.
We’re excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group’s overview page, you couldn’t see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.
We welcome feedback about this change in epic 16777.
In GitLab 17.9 the Composition Analysis team starts the transition to Dependency Scanning using SBOM with the new Dependency Scanning analyzer. This analyzer will be a replacement for Gemnasium, which will reach end of support in 18.0, remaining available for use through GitLab 19.0.
The Dependency Scanning using SBOM approach will better support customers through expansion of language support, a tighter integration and experience within the GitLab platform, and a shift towards industry standard report types (SBOM-based scanning and reporting). As of GitLab 17.9, the new Dependency Scanning analyzer will be enabled by default in the latest Dependency Scanning CI/CD template (Dependency-Scanning.latest.gitlab-ci.yml) for the following project and file types:
conda-lock.yml file.podfile.lock file.cargo.lock file.package.resolved file.With this change we are introducing a new CI/CD variable: DS_ENFORCE_NEW_ANALYZER which is set to false by default.
This approach ensures that all existing customers of the latest template continue to use the Gemnasium analyzer by default and it enables automatically the new Dependency Scanning analyzer for the file types listed above.
Existing customers who wish to migrate to the new Dependency Scanning analyzer can set DS_ENFORCE_NEW_ANALYZER to true (at the project, group, or instance level). You can read more about this change in the deprecation announcement and the associated migration guide.
Customers who want to entirely prevent the use of the new Dependency Scanning analyzer must set the CI/CD variable DS_EXCLUDED_ANALYZERS to dependency-scanning.
In GitLab 17.9, we added support for license scanning on Swift packages. This will allow users who use Swift within their projects to better understand the licensing of their Swift packages.
This data is available to composition analysis users through the Dependency List, SBOM reports, and GraphQL API.
GitLab Advanced SAST now offers multi-core scanning as an opt-in feature to improve performance. This can reduce scan duration significantly, especially for larger codebases.
To enable it, set the SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable to --multi-core N, where N is the desired number of cores to use.
You should only set this variable on the gitlab-advanced-sast job, not any other jobs.
Check the documentation for important guidance on how to select the right value.
We’re working to enable this performance improvement by default; this is tracked in issue 517409.
In GitLab 17.2, we released the ability for group owners to apply and remove compliance frameworks for all projects in a group by using the group’s compliance center.
We have expanded this to now allow group owners to also apply and remove compliance frameworks at the project level. This will make it even easier for group owners to apply and monitor compliance frameworks at the project level.
The ability to apply and remove compliance frameworks at the project level is only available for group owners and not project owners.
Workspace extensions now support enabling proposed APIs, improving compatibility and reliability in production environments. This update allows extensions that depend on proposed APIs to run without errors, including critical development tools like the Python Debugger. The change expands API access while maintaining stability.
Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.
In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don’t require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.
To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.
The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2025 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).
To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.
We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.
We’re excited to introduce a new capability for pipeline execution policies that allows you to enforce custom stages into your CI/CD pipelines in Inject mode. This feature provides greater flexibility and control over your pipeline structure while maintaining security and compliance requirements, supplying you with:
How does it work?
The new and improved inject_policy strategy for pipeline execution policies allows you to define custom stages in your policy configuration. These stages are then intelligently merged with your project’s existing stages using a Directed Acyclic Graph (DAG) algorithm, ensuring proper ordering and preventing conflicts.
For example, you can now easily inject a custom security scanning stage between your build and deploy stages.
The inject_policy stage replaces inject_ci which will be deprecated, allowing you to opt into the inject_policy mode to gain the benefits. The inject_policy mode will become the default when configuring policies with Inject in the policy editor.
self_rotate scopeYou can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.
Thank you Stéphane Talbot and Anthony Juckel for your contribution!
You can now view inactive group and project access tokens in the UI. Previously, GitLab instantly deleted project and group access tokens after they expired or were revoked. This lack of a record of inactive tokens made auditing and security reviews more difficult. GitLab now retains inactive group and project access token records for 30 days, which helps teams track token usage and expiration for compliance and monitoring purposes.
Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.
Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!
You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.
You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.
We’ve streamlined the process of creating multiple child items by keeping the form open after each submission, making it easier to add multiple entries without extra clicks. This update saves you time and ensures a smoother workflow when managing your tasks.
The Work Items GraphQL API now includes additional query filters that let you filter by:
These new filters give you more control when querying and organizing work items through the API.
To ensure secure management of security policies and prevent disruption to enabled and enforced policies, we’ve added protection to prevent deletion of security policy projects that are in active use.
If a security policy project is linked to any groups or projects, the links must be removed before the security policy project can be deleted.
On the Dependencies list in a project, you can now filter by the package name using the Component filter.
Previously, you could not search for packages in the Dependencies list for a project level. Now, setting the Component filter will find packages that contain the specified string.
In the Vulnerability Report for a project, you can now filter the results by vulnerability identifier so you can find specific vulnerabilities (like CVEs or CWEs) that are in your project. You can use the identifier in conjunction with other filters like the severity, status, or tool filters. The vulnerability identifier filter is limited to reports with 20,000 vulnerabilities or less.
We’ve made merge request approval policies more flexible by adding the ability to assign custom roles as approvers.
You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals.
You can now use search and filter capabilities in the Credentials Inventory. This makes it easier to identify tokens and keys which fall within certain user-defined parameters, including tokens that expire within a certain window. Previously, the entries in the Credentials Inventory were presented as a static list.
Previously, when a user authorized an OAuth application, no audit event was generated. However, this event is important for security teams to monitor the OAuth applications authorized by users on a specific GitLab instance.
With this release, GitLab now provides a User authorized an OAuth application audit event to track when users successfully authorize OAuth applications. This new audit event further improves your ability to audit your GitLab instance.
You can now use the API to clear all two-factor authentication (2FA) registrations for an individual enterprise user. Previously, this was only possible in the UI. Using the API allows for automated and bulk operations, saving time when 2FA resets need to be done at scale.
You can now set a custom email address to receive email notifications for service accounts. When a custom email address is specified when creating a service account, GitLab sends notifications to that address. Each service account must use a unique email address. This can help you monitor processes and events more effectively.
Thank you Gilles Dehaudt, Étienne Girondel, Kevin Caborderie, Geoffrey McQuat, Raphaël Bihore from the SNCF Connect & Tech team for your contribution!
You can now configure additional group memberships when using multiple OIDC providers. Previously, if you configured multiple OIDC providers, you were limited to a single group membership.
When rotating an access token for a service account, you can now use the expires_at attribute to set a custom expiration date. Previously, tokens automatically expired seven days after rotation. This allows for more granular management of token lifetimes, enhancing your ability to maintain secure access controls.
Pipeline execution policies now support additional merge request variables, allowing you to create more sophisticated policies that take into account information related to the merge request. This provides more targeted and efficient control over CI/CD enforcement. The following variables are now supported:
CI_MERGE_REQUEST_SOURCE_BRANCH_SHACI_MERGE_REQUEST_TARGET_BRANCH_SHACI_MERGE_REQUEST_DIFF_BASE_SHAWith this enhancement, you can:
You can create custom roles with the Read compliance dashboard permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Maintainer or Owner role.
We’re also releasing GitLab Runner 17.9 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On January 16, 2025, GitLab 17.8 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Through the Co-Create Program, Océane Legrand has been leading efforts to enhance the Conan package registry feature set, collaborating with Juan Pablo Gonzalez. Their work has focused on bringing the feature closer to GA readiness while implementing Conan version 2 support. This collaboration demonstrates how the Co-Create Program can drive significant improvements to GitLab’s package registry capabilities.
They were nominated by Raimund Hook, Senior Fullstack Engineer, Contributor Success at GitLab, who highlighted their persistent collaboration and continuous iteration on the Conan Package Registry features. Their work exemplifies GitLab values and will benefit all Conan users on the platform.
Océane Legrand is a Full Stack Developer at Scania where she works on maintaining their self-hosted GitLab instance on AWS. “The work I’m doing in open source impacts both GitLab and Scania,” says Océane. “Contributing through the Co-Create Program has given me new skills, like experience with Ruby and background migrations. When my team at Scania faced an issue during an upgrade, I was able to help troubleshoot because I’d already encountered it through the program.”
Learn more about GitLab’s Co-Create Program where customers work directly with our product and engineering teams to develop new features and enhance existing ones.
We’re thrilled to announce the rollout of protected container repositories, a new feature in GitLab’s container registry that addresses security and control challenges in managing container images. Organizations often struggle with unauthorized access to sensitive container repositories, accidental modifications, lack of granular control, and difficulties in maintaining compliance. This solution provides enhanced security through strict access controls, granular permissions for push, pull, and management operations, and seamless integration with GitLab CI/CD pipelines.
Protected container repositories offers value to users by reducing the risk of security breaches and accidental changes to critical assets. This feature streamlines workflows by maintaining security without sacrificing development speed, improves overall governance of the container registry, and provides peace of mind knowing that important container assets are protected according to organizational needs.
This feature and the protected packages feature are both community contributions from gerardo-navarro and the Siemens crew. Thank you Gerardo and the rest of the crew from Siemens for their many contributions to GitLab! If you are interesting in learning more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.
While GitLab has long supported creating releases from Git tags and tracking deployments, this information previously lived in multiple separate places that were difficult to piece together. Now, you can see all deployments related to a release directly on the release page. Release managers can quickly verify where a release has been deployed and which environments are pending deployment. This complements the existing deployment page integration that shows release notes for tagged deployments.
We would like to express our gratitude to Anton Kalmykov for contributing both features to GitLab.
When creating machine learning models, data scientists often experiment with different parameters, configurations, and feature engineering to improve the performance of the model. Keeping track of all this metadata and the associated artifacts so that the data scientist can later replicate the experiment is not trivial. Machine learning experiment tracking enables them to log parameters, metrics, and artifacts directly into GitLab, giving easy access later on while also keeping all experimental data within your GitLab environment. This feature is now generally available with enhanced data displays, enhanced permissions, deeper integration with GitLab, and bug fixes.
We are excited to introduce the limited availability of hosted runners on Linux for GitLab Dedicated.
Managing fleets of runners can be complex and require significant experience to ensure all CI/CD jobs can scale to meet the demands of developers.
Hosted runners for GitLab Dedicated allow you to use fully managed runners for CI/CD jobs. They eliminate the need to maintain your own runner infrastructure, and provide the same security, flexibility, and efficiency of GitLab Dedicated to runners.
Hosted runners scale automatically to meet your CI/CD demands to ensure optimal performance during peak times and for large projects. The limited availability release includes Linux runners in various sizes, ranging from 2 to 32 vCPUs, with 8 to 128 GB of memory.
To request access to hosted runners for GitLab Dedicated during the limited availability phase, contact your GitLab representative.
We bring M2 Pro performance to mobile DevOps teams!
With up to 2 times the performance of M1 runners and 6 times the performance of x86-64 macOS runners, you can increase your development team’s velocity when building and deploying applications.
Fully integrated to GitLab CI/CD and available on-demand, teams can now seamlessly create, test, and deploy applications faster for the Apple ecosystem.
Try out the new M2 Pro runners today by using saas-macos-large-m2pro as the tag in your .gitlab-ci.yml file.
Data scientists and Machine Learning engineers primarily work in Python environments, but integrating their machine learning workflows with GitLab’s MLOps features often requires context switching and understanding of GitLab’s API structure. This can create friction in their development process and slow down their ability to track experiments, manage model artifacts, and collaborate with team members.
The new GitLab MLOps Python client provides a seamless, Pythonic interface to GitLab’s MLOps features. Data scientists can now interact with GitLab’s experiment tracking and model registry capabilities directly from their Python scripts and notebooks. The client includes:
This integration allows data scientists to focus on model development while automatically capturing their ML lifecycle metadata in GitLab. The Python client works seamlessly with existing ML workflows and requires minimal setup, making GitLab’s MLOps features more accessible to the data science community.
We welcome the wider Python and data science community to contributions and share feedback directly in our project’s repository
When you mark a group for deletion, you need visibility into all affected subgroups and projects. Previously, only the group marked for deletion displayed a “Pending deletion” label, but not their subgroups and projects, making it difficult to identify which content was scheduled for deletion.
Now, when a group is marked for deletion, all of its subgroups and projects will display a “Pending deletion” label. This improved visibility helps you quickly distinguish between active and soon-to-be deleted content across your entire group hierarchy.
You can now keep track of multiple discussions and mentions within a single issue or merge request. With the new multiple to-do items feature, you’ll receive separate to-do items for each mention or action, ensuring you don’t miss important updates or requests for your attention. This enhancement helps you manage your work more effectively and respond to your team’s needs more efficiently.
Project creation can be restricted to specific roles in a group using the Allowed to create projects setting. The Owner role is now available as an option, enabling you to restrict new project creation to users with the Owner role for the group. This role was previously unavailable in the selection options.
Thank you @yasuk for this community contribution!
It’s important to fix exposed secrets quickly to minimize the risk of attackers using exposed credentials to break into your systems. Proper remediation requires multiple steps beyond just removing the secret, such as rotating credentials and investigating potential unauthorized access. To help keep your systems secure, secret detection now includes specific remediation steps for each type of detected secret. This guidance helps you systematically address exposures and reduce the risk of security breaches. Remediation steps will appear on all vulnerabilities upon the completion of a pipeline.
Previously, when a vulnerability was no longer detected, we did not provide users a way to see when or where a vulnerability was resolved. Now, we display a link to the commit SHA where the vulnerability was resolved, providing better traceability and insight into the resolution process. This makes it easier for security and development teams to collaborate and manage vulnerabilities more effectively.
You can now use roles as Code Owners in your CODEOWNERS file to manage role-based expertise and approvals more efficiently. Instead of listing individual users or creating groups, you can use the following syntax:
@@developers - References all users with the Developer role.@@maintainers - References all users with the Maintainer role.@@owners - References all users with the Owner role.For example, add * @@maintainers to require approval from any maintainer for all changes in the repository.
This simplifies Code Owner management as team members join, leave, or change roles in your project. The CODEOWNERS file remains current without manual updates, because GitLab automatically includes all users who have the specified role.
Previously, when you suspended Flux reconciliation from the dashboard for Kubernetes, there was no clear indicator of the suspended state. We’ve added a new “Paused” status to the existing set of status indicators, making it clear when Flux reconciliation is suspended and providing better visibility into the state of your deployments.
On the dashboard for Kubernetes, finding specific pods in large deployments can be time-consuming. A new search bar lets you quickly filter pods by name. The search works across all available pods, and you can combine it with status filters to find exactly the pods you need to monitor or troubleshoot.
Previously, merge request approval policies supported only a single approval rule per policy, allowing for one set of approvers stacked with an “OR” condition. As a result, it was more challenging to enforce layered security approvals from varied roles, individual approvers, or separate groups.
With this update, you can create up to five approval rules for each merge request approval policy, allowing for more flexible and robust approval policies. Each rule can specify different approvers or roles and each rule is evaluated independently. For example, security teams can define complex approval workflows such as requiring one approver from Group A and one from Group B, or one from a specific role and another from a specified group, ensuring compliance and enhanced control in sensitive workflows.
Example uses of this improvement include:
You can now set a primary domain in GitLab Pages to automatically redirect all requests from custom domains to your primary domain. This helps maintain SEO rankings and provides a consistent brand experience by directing visitors to your preferred domain, regardless of which URL they initially use to access your site.
We’re thrilled to introduce support for protected PyPI packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.
From GitLab 17.8, you can protect PyPI packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.
You now have more flexibility in categorizing your epics with an expanded set of color options, including pre-existing values and custom RGB or hex codes. This enhanced visual customization allows you to easily associate epics with squads, company initiatives, or hierarchy levels, making it simpler to prioritize and organize your work on roadmaps and epic boards.
Your administrator must enable the new look for epics.
Navigating your epic hierarchy just got easier with the redesigned Ancestry widget, now prominently displayed at the top of each epic in a breadcrumb-like format. You can quickly grasp the relationships between epics by seeing both immediate and ultimate parents at a glance, helping you maintain a clear overview of your project structure and easily move between related epics.
Your administrator must enable the new look for epics.
You can now easily communicate the progress of your projects with the new health status feature for epics. By setting the status to “On track,” “Needs attention,” or “At risk,” you’ll have a quick visual indicator of your epic’s health, allowing you to manage risk and keep stakeholders informed about the project’s overall status.
Your administrator must enable the new look for epics.
You can now easily manage your epic hierarchy by adding a parent directly from an epic, just as you would for an issue. This streamlined process gives you more flexibility in organizing your work, allowing you to quickly establish relationships between epics and maintain a clear structure for your projects.
Your administrator must enable the new look for epics.
You can now track time directly in epics, giving you more granular control over your project’s time management. This new feature allows you to log time spent on different aspects of your project, helping you monitor progress, stay on schedule, and keep your budget in check as you work through sprints and milestones.
When viewing epic detail, planners need to be able to see which child issues are planned into iterations (sprints) and which are not yet planned. This will allow teams to more easily make sure that all defined work is slated into sprints.
For epics, your administrator must enable the new look for epics.
Supercharge your workflow automation with the epic webhooks, allowing you to receive real-time updates in your preferred tools whenever changes occur in your epics. By integrating GitLab with your other services, you can enhance collaboration, stay on top of project developments, and streamline your processes without constantly switching between applications.
Your administrator must enable the new look for epics.
Introducing a webhook integration that generates events for actions related to vulnerabilities to allow you to automate and integrate with external resources. For example, events are generated when vulnerabilities are created or the status of a vunerability changes.
override_ci strategyIn pipeline execution policies, the override_ci strategy now supports the use of workflow rules to aid in policy enforcement for jobs defined in the policy, as well as jobs defined in the project’s configuration when using include:project. By defining workflow rules in the policy, you can filter out jobs executed by the pipeline execution policy based on particular rules, such as by configuring rules that prevent the use of branch pipelines in projects.
To isolate the use of workflow rules to target only jobs defined in your policy, the best practice is to define the rules for the job instead of globally in the policy. Alternatively, you can group jobs and rules using a separate include field.
Previously, when using the override_ci strategy, workflow rules could only be applied to jobs defined in the pipeline execution policy.
The inject_ci strategy remains unchanged and workflow rules can only be used to control when policy jobs are enforced, without affecting the project’s workflow rules.
skip_ci configurable for pipeline execution policiesWe’ve introduced a new configuration option for Pipeline Execution Policies (PEPs) that allows for more flexibility in handling the [skip ci] directive. This feature addresses scenarios where certain automated processes, such as semantic releases, where it’s necessary to bypass pipeline execution while still ensuring critical security and compliance checks are performed.
To use this feature, set skip_ci to allowed: false in the pipeline execution policy YAML configuration or enable Prevent users from skipping pipelines in the policy editor. Then, specify the users or service accounts that are allowed to use [skip ci]. By default all users will be blocked from skipping pipeline execution jobs unless they are excluded within the skip_ci configuration as an exception.
To improve the scalability of global scheduled scan execution policies, we have introduced a new capability to configure a time window in a scan execution policy. The time_window property defines the time period in which the policy creates and executes new schedules to ensure optimal performance.
To use the new property, update your policy using YAML mode and follow the time_window schema. You can provide a value in seconds for the window of time in which the schedules should run. For example, 86400 for a 24 hour time window. Then supply the distribution: random field and value to enforce the schedules to execute at random times across the defined time window.
With GitLab 17.8, we have made changes to the backend to ensure the compliance center remains quick and responsive, even if you have 1,000’s of compliance frameworks in the Frameworks report tab of the compliance center.
Additionally, when looking for more information and clicking on a framework in the Frameworks tab, GitLab returns up to 1,000 projects that are attached to that particular framework as part of the information in the right-hand side pop up menu.
Administrators can now control pipeline resource usage by setting CI/CD limits for their GitLab Community Edition installations. Previously, this feature was only available in GitLab Enterprise Edition.
On December 19, 2024, GitLab 17.7 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Vedant has been an outstanding community contributor, known for his proactive approach to contributing, his commitment to delivering, and his collaboration skills. He excels at taking on feedback, incorporating it into his work, and seeking assistance when needed, ensuring that his contributions are not only completed but also meet GitLab’s standards.
His contributions include streamlining project management processes with Abstracted work item attributes to a single list/board, Ordering of metadata on work items, and feature development in Remember the collapsed state of work item widgets. Vedant also fixed links in the UI to documentation (1, 2), helping the technical writing team as part of an important effort to improve UX across the entire product.
Amanda Rueda, Sr. Product Manager, Product Planning at GitLab, nominated Vedant and highlighted his proactive and community-oriented mindset, “Vedant’s work not only addresses user needs but through his contributions, he is co-creating a more stable and reliable GitLab environment. By contributing to bug fixes, usability improvements, and maintenance efforts, he has played a vital role in enhancing the overall quality of the product. His proactive approach and cross-group contributions embody GitLab’s core values of iteration, customer collaboration, and continuous improvement, making him a standout contributor in the community.”
“Thanks to everyone who helped me achieve my contributions,” says Vedant. “So grateful that I am able to make a good impact and looking forward to more contributions.”
Vedant is a Frontend Engineer at Atlan, an active metadata platform for modern data teams, and a Google Summer of Code 2024 Mentor.
We are so grateful to Vedant for all of his contributions and to all of our open source community for contributing to GitLab!
We’ve introduced the new Planner role to give you tailored access to Agile planning tools like epics, roadmaps, and Kanban boards without over-provisioning permissions. This change helps you collaborate more effectively while keeping your workflows secure and aligned with the principle of least privilege.
Instance administrators can now configure an allowlist to control which integrations can be enabled on a GitLab instance. If an empty allowlist is configured, no integrations are allowed on the instance. After an allowlist is configured, new GitLab integrations are not on the allowlist by default.
Previously enabled integrations that are later blocked by the allowlist settings are disabled. If these integrations are allowed again, they are re-enabled with their existing configuration.
The new method of user contribution and membership mapping is now available when you migrate between GitLab instances by direct transfer. This feature offers flexibility and control for both users managing the import process and users receiving contribution reassignments. With the new method, you can:
When you reassign a contribution to a user on the destination instance, the user can accept or reject the reassignment.
For more information, see streamline migrations with user contribution and membership mapping. To leave feedback, add a comment to issue 502565.
GitLab’s security scanning tools help identify known vulnerabilities and potential weaknesses in your application code. Scanning feature branches surfaces new weaknesses or vulnerabilities so they can be remediated before merging. In the case of vulnerabilities already in your project’s default branch, fixing these in a feature branch will mark the vulnerability as no longer detected when the next default branch scan runs. While it is informative to know which vulnerabilities are no longer detected, each must still be manually marked as Resolved to close them. This can be time consuming if there are many of these to resolve, even when using the new Activity filter and bulk-changing status.
We are introducing a new policy type Vulnerability Management policy for users who want vulnerabilities automatically set to Resolved when no longer detected by automated scanning. Simply configure a new policy with the new Auto-resolve option and apply it to the appropriate project(s). You can even configure the policy to only Auto-resolve vulnerabilities of a certain severity or from specific security scanners. Once in place, the next time the project’s default branch is scanned, any existing vulnerabilities that are no longer found will be marked as Resolved. The action updates the vulnerability record with an activity note, timestamp when the action occurred, and the pipeline the vulnerability was determined to be removed in.
You can now use the UI to rotate personal, project, and group access tokens. Previously, you had to use the API to do this.
Thank you shangsuru for your contribution!
Central DevOps teams often need to track where their CI/CD components are used across pipelines to better manage and optimize them. Without visibility, it’s challenging to identify outdated component use, understand adoption rates, or support component life cycles.
To address this, we’ve added a new GraphQL query that enables DevOps teams to view a list of projects where a component is used across their organization’s pipelines. This capability empowers DevOps teams to enhance productivity and make better decisions by providing crucial insights.
We are excited to introduce the small hosted runner on Linux Arm for GitLab.com, available for all tiers. This 2 vCPUs Arm runner is fully integrated with GitLab CI/CD and allows you to build and test applications natively on the Arm architecture.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
Because of a bug, FIPS Linux packages for GitLab 17.6 and earlier did not use the system Libgcrypt, but the same Libgcrypt bundled with regular Linux packages.
This issue is fixed for all FIPS Linux packages for GitLab 17.7, except for AmazonLinux 2. The Libgcrypt version of AmazonLinux 2 is not compatible with the GPGME and GnuPG versions shipped with the FIPS Linux packages.
FIPS Linux packages for AmazonLinux 2 will continue to use the same Libgcrypt bundled with the regular Linux packages, otherwise we would have to downgrade GPGME and GnuPG.
We’ve updated Advanced SAST to detect the following vulnerability classes more accurately:
We’ve also improved detection of user input sources for C# (ASP.NET) and Java (JSF, HttpServlet) and updated severity levels for consistency.
To see which types of vulnerabilities Advanced SAST detects in each language, see Advanced SAST coverage. To use this improved cross-file, cross-function scanning, enable Advanced SAST. If you’ve already enabled Advanced SAST, the new rules are automatically activated.
In GitLab 17.7, we added support for the Known Exploited Vulnerabilities Catalog (KEV). The KEV Catalog is maintained by CISA and curates listings of CVEs that have been exploited in the wild. You can leverage KEV to better prioritize scan results and to help evaluate the potential impact a vulnerability may have on your environment.
This data is available to composition analysis users through GraphQL. There is planned work to support displaying this data in the GitLab UI.
The Advanced SAST code flow view is now available wherever vulnerabilities are shown, including the:
The new views are enabled on GitLab.com. On GitLab self-managed, the new views are on by default starting in GitLab 17.7 (MR changes view) and GitLab 17.6 (all other views). For details on supported versions and feature flags, see code flow feature availability.
To learn more about Advanced SAST, see the announcement blog.
/help command in GitLab Duo ChatDiscover GitLab Duo Chat’s powerful features! Just type /help in the chat message field to explore everything it can do for you.
Give it a try and see how GitLab Duo Chat can make your work smoother and more efficient.
environment.action: access and prepare resets the auto_stop_in timerPreviously, when using the action: prepare, action: verify, and action: access jobs together with the auto_stop_in setting, the timer was not reset. Starting in 18.0, action: prepare and action: access will reset the timer, while action: verify leaves it untouched.
For now, you can change to the new implementation by enabling the prevent_blocking_non_deployment_jobs feature flag.
Multiple breaking changes are intended to differentiate the behavior of the environment.action: prepare | verify | access values. The environment.action: access keyword will remain the closest to its current behavior, except for the timer reset.
To prevent future compatibility issues, you should review your use of these keywords. Learn more about these proposed changes in the following issues:
This release adds full support for Kubernetes version 1.31, released in August 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
For more information, see our Kubernetes support policy and other supported Kubernetes versions.
To use the dashboard for Kubernetes, you need to select an agent for Kubernetes connection from the environment settings, and optionally configure a namespace and a Flux resource to track the reconciliation status. In GitLab 17.6, we added support for selecting an agent with a CI/CD configuration. However, configuring the namespace and the Flux resource still required you to use the UI or make an API call. In 17.7, you can fully configure the dashboard using the CI/CD syntax with the environment.kubernetes.namespace and environment.kubernetes.flux_resource_path attributes.
Group and project access tokens are now visible in the credentials inventory on GitLab.com. Previously, only personal access tokens and SSH keys were visible. Additional token types in the inventory allow for a more complete picture of credentials across the group.
Previously, token expiration email notifications were only sent seven days before expiry. Now, these notifications are also sent 30 and 60 days before expiry. The increased frequency and date range of notifications makes users more aware of tokens that may be expiring soon.
In previous versions of GitLab, emoji support was limited to an older Unicode standard, which meant some newer emojis were unavailable.
GitLab 17.7 introduces support for Unicode 15.1, bringing the latest emoji additions. This includes exciting new options like the t-rex 🦖, lime 🍋🟩, and phoenix 🐦🔥, allowing you to express yourself with the most up-to-date symbols.
Additionally, this update enhances emoji diversity, ensuring greater representation across cultures, languages, and identities, helping everyone feel included when communicating on the platform.
In this version, we’re introducing the ability to set a default text editor for a more personalized editing experience. With this change, you can now choose between the rich text editor, the plain text editor, or opt for no default, allowing flexibility in how you create and edit content.
This update ensures smoother workflows by aligning the editor interface with individual preferences or team standards. With this enhancement, GitLab continues to prioritize customization and usability for all users.
When creating a personal, project, group, or impersonation access token, you can now optionally enter a description of that token. This helps provide extra context about the token, such as where and how is it used.
With this release, you can now enable secret push protection on all projects in your group via the REST API and the GraphQL API. This allows you to efficiently enable secret push protection on a per-group basis instead of project by project. Audit events are logged every time push protection is enabled or disabled.
Group Owners can now use a dedicated API endpoint to list enterprise users and any associated attributes.
The Owner base role is no longer available when creating a custom role as it provided no additional value because permissions are additive. Existing custom roles with the Owner base role are not impacted by this change.
We continue to make iterative and important improvements to the compliance center’s user experience for both groups and projects.
With GitLab 17.7, we shipped two key improvements:
Please note that adding or editing frameworks is still done on groups, not projects.
On November 21, 2024, GitLab 17.6 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Joel was recognized for being an invaluable contributor to our CI components, offering insightful feedback on merge requests, and thoughtful comments on complex discussions. His contributions include UI polish for the CI/CD catalog, highly requested documentation improvements for the GitLab Terraform Provider, job log timestamps, and providing feedback to the UI/UX team.
Joel is a Staff Software Engineer at HackerOne and was nominated by Lee Tickett, Staff FullStack Engineer, Contributor Success at GitLab, for his contributions and for providing valuable feedback.
Gina Doyle, Senior Product Designer at GitLab, added to the nomination. “There was a lot of discussion going on internally that led the MR process to be more complicated,” says Gina. “But Joel stayed strong and active within the discussion and completed the contribution.”
“Joel also contributed to the UI polish on the CI/CD catalog issue,” says Sunjung Park, Staff Product Designer at GitLab. “It makes our user interface beautiful and consistent with other areas.”
We are so grateful to Joel for all of his contributions and to all of our open source community for contributing to GitLab!
You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for GitLab Duo Chat. This feature is in beta and available with an Ultimate and Duo Enterprise subscription on self-managed GitLab environments.
With self-hosted models, you can use models hosted either on-premise or in a private cloud as the source for GitLab Duo Chat or Code Suggestions (introduced as a beta feature in GitLab 17.5). For Code Suggestions, we currently support open-source Mistral models on vLLM or AWS Bedrock, Claude 3.5 Sonnet on AWS Bedrock, and OpenAI models on Azure OpenAI. For Chat, we currently support open-source Mistral models on vLLM or AWS Bedrock, and Claude 3.5 Sonnet on AWS Bedrock. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.
Please leave feedback in issue 501268.
After you’ve carefully crafted your changes and prepared a merge request, the next step is to identify reviewers who can help move it forward. Identifying the right reviewers for your merge request involves understanding who the right approvers are, and who might be a subject matter expert (CODEOWNER) for the changes you’re proposing.
Now, when assigning reviewers, the sidebar creates a connection between the approval requirements for your merge request and reviewers. View each approval rule, then select from approvers who can satisfy that approval rule and move the merge request forward for you. If you use optional CODEOWNER sections those rules are also shown in the sidebar to help you identify appropriate subject matter experts for your changes.
Enhanced reviewer assignments is the next evolution of applying intelligence to assigned reviewers in GitLab. This iteration builds on what we’ve learned from suggested reviewers, and how to effectively identify the best reviewers for moving a merge request forward. In upcoming iterations of reviewer assignments, we’ll continue to enhance the intelligence used to recommend and rank possible reviewers.
GitLab workspaces now offer support for private container registries. With this setup, you can pull container images from any private registry of your choice. As long as your Kubernetes cluster has a valid image pull secret, you can reference the secret in your GitLab agent configuration.
This feature simplifies workflows, especially for teams that use custom or third-party container registries, and improves the flexibility and security of containerized development environments.
The extension marketplace is now available in workspaces. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience. Choose from thousands of extensions to boost your productivity or customize your workflow.
The extension marketplace is disabled by default. To get started, go to your user preferences and enable the extension marketplace. For enterprise users, only users with the Owner role for a top-level group can enable the extension marketplace.
With this release, a workspace now stops rather than terminates after the configured timeout has elapsed. This feature means you can always restart your workspaces and pick up where you left off.
By default, a workspace automatically:
You can configure these settings in your GitLab agent configuration.
With this feature, a workspace remains available for approximately one month after it was stopped. This way, you get to keep your progress while optimizing workspace resources.
Have you ever wondered what might be included in a deployment you’ve been asked to approve? In past versions, you could create a release with a detailed description about its content and instructions for testing, but the related environment-specific deployment did not show this data. We are happy to share that GitLab now displays the release notes under the related deployment details page.
Because GitLab releases are always created from a Git tag, the release notes are shown only on deployments related to the tag-triggered pipeline.
This feature was contributed to GitLab by Anton Kalmykov. Thank you!
Previously, we announced that the default CI/CD job token (CI_JOB_TOKEN) behavior will change in GitLab 18.0, requiring you to explicitly add indvidual projects or groups to your project’s job token allowlist if you want them to continue to be able to access your project.
Now, we are giving self-managed and Dedicated instance administrators the ability to enforce this more secure setting on all projects on an instance. After you enable this setting, all projects will need to make use of their allowlist if they want to use CI/CD job tokens for authentication. Note: We recommend enabling this setting as part of a strong security policy.
Previously it was difficult to track which other projects were using accessing your project by authenticating with CI/CD job tokens. To make it easier for you to audit and control access to your project, we’ve added an authentication log.
With this authentication log, you can view the list of other projects that have used a job token to authenticate with your project, both in the UI and as a downloadable CSV file. This data can be used to audit project access and aid in populating the job token allowlist to enable stronger control over which projects can access your project.
Users require the ability to view vulnerabilities in groups. This will help security analysts optimize their triage tasks by utilizing bulk actions. In addition users can see how many vulnerabilities match their group; i.e. how many OWASP Top 10 vulnerabilities are there?
GitLab’s model registry, now generally available, is your centralized hub for managing machine learning models as part of your existing GitLab workflow. You can track model versions, store artifacts and metadata, and maintain comprehensive documentation in the model card.
Built for seamless integration, the model registry works natively with MLflow clients and connects directly to your CI/CD pipelines, enabling automated model deployment and testing. Data scientists can manage models through an intuitive UI or existing MLflow workflows, while MLOps teams can leverage semantic versioning and CI/CD integration for streamlined production deployments all within the GitLab API.
Please feel free to drop us a note in our feedback issue and we’ll get back in touch! Get started today by going to Deploy > Model registry in your GitLab instance.
As a GitLab Dedicated tenant administrator, you can now use Switchboard to set up outbound private links and private hosted zones. You can also monitor your network connections by viewing periodic snapshots in Switchboard.
Outbound private links and private hosted zones establish secure network connectivity between resources in your AWS account and GitLab Dedicated.
GitLab offers a wide range of security scanners such as SAST, secret detection, dependency scanning, container scanning, and more so that you can check your applications for security vulnerabilities.
You need to have a way to show auditors and relevant compliance authorities that your applications have adhered to regulatory standards that require you to have security scanners set up for your repositories.
To help you demonstrate adherence to these standards, this release includes two new checks as part of the standard adherence report in the Compliance Centre. These new checks check whether SAST and DAST has been enabled for projects within a group. The checks confirm that the SAST and DAST security scanners correctly ran in a project and the pipeline results has the correct resulting artifacts.
In this release, we’ve added project events to group webhooks. Project events are triggered when:
These events are triggered for group webhooks only.
In previous versions of GitLab, the user list displayed on the GitLab Duo seat assignment page could not be filtered, making it difficult to see which users had previously been assigned a GitLab Duo seat. Now, you can filter your user list by Assigned seat = Yes or Assigned seat = No to see to see which users are currently assigned or not assigned a GitLab Duo seat, allowing for ease in adjusting seat allocations.
All users on self-managed instances will receive an email when they are assigned a GitLab Duo seat.
Previously, those assigned a Duo Enterprise seat or those granted access by bulk assignment would not be notified. You wouldn’t know you were assigned a seat unless someone told you, or you noticed new functionality in the GitLab UI.
To disable this email, an administrator can disable the duo_seat_assignment_email_for_sm feature flag.
In GitLab 17.6, we added support for the Exploit Prediction Scoring System (EPSS). EPSS gives each CVE a score between 0 and 1 indicating the probability of the CVE being exploited in the next 30 days. You can leverage EPSS to better prioritize scan results and to help evaluate the potential impact a vulnerability may have on your environment.
This data is available to composition analysis users through GraphQL.
It’s now easier to programatically enable secret push protection. We’ve updated the application settings REST API, allowing you to:
Audit events are now logged when a secret push protection exclusion is applied. This enables security teams to audit and track any occurence when a secret on the project’s exclusions list is allowed to be pushed.
Repository X-Ray enriches code generation requests for GitLab Duo Code Suggestions by providing additional context about a project’s dependencies to improve the accuracy and relevance of code recommendations. This improves the quality of code generation. Previously, Repository X-Ray used a CI job that you had to configure and manage.
Now, when a new commit is pushed to your project’s default branch, Repository X-Ray automatically triggers a background job that scans and parses the applicable configuration files in your repository.
The latest update to the GitLab Duo plugin introduces advanced proxy authentication. This enables developers to connect seamlessly in environments with strict corporate firewalls. Building on our existing HTTP proxy support, this enhancement allows for authenticated connections. It ensures secure and uninterrupted access to Duo features in VS Code and JetBrains IDEs.
This update is crucial for developers needing secure, authenticated connections in restricted network environments. It ensures all Duo features remain available without compromising security.
Some merge requests may need to be held for merging until after a certain date or time. When that date and time does pass you need to find someone with permissions to merge and hope they’re available to take care of it for you. If this is after hours or the timeline is critical you may need to prepare folks well in advance for the task.
Now, when you create or edit a merge request you can specify a merge after date. This date will be used to prevent the merge request from being merged until it has passed. Using this new capability with our previously released improvements to auto-merge gives you the flexibility to schedule merge requests to merge in the future.
A big thank you to Niklas van Schrick for the amazing contribution!
glab agent bootstrap commandIn the last release, we introduced support for easy agent bootstrapping to the GitLab CLI tool. GitLab 17.6 further improves the glab cluster agent bootstrap command with support for custom Helm values. You can use the --helm-release-values and --helm-release-values-from flags to customize the generated HelmRelease resource.
To use the dashboard for Kubernetes, you need to select an agent for Kubernetes connection from the environment settings. Until now, you could select the agent only from the UI or (from GitLab 17.5) the API, which made configuring a dashboard from CI/CD difficult. In GitLab 17.6, you can configure an agent connection with the environment.kubernetes.agent syntax.
In addition, issue 500164 proposes to add support for selecting a namespace and Flux resource from your CI/CD configuration.
There are now additional audit events for privileged settings-related administrator actions. A record of when these settings were changed can help improve security by providing an audit trail.
With this release, when a merge request is merged, a new audit event type called merge_request_merged is triggered that contains key information about
the merge request, including:
It is now possible to disable the OTP authenticator and WebAuthn devices individually or simultaneously. Previously, if you disabled the OTP authenticator, the WebAuthn device(s) were also disabled. Because the two now operate independently, there is more granular control over these authentication methods.
Administrators can use the new token information API to get information about personal access tokens, deploy tokens, and feed tokens. Unlike other API endpoints that expose token information, this endpoint allows administrators to retrieve token information without knowing the type of the token.
Thank you Nicholas Wittstruck and the rest of the crew from Siemens for your contribution!
GitLab optionally sends an email when a sign-in from a new location is detected. Previously, this email only contained the IP address, which is difficult to correlate to a location. This email now contains city and country location information as well.
Thank you Henry Helm for your contribution!
When a merge request approval policy is configured to prevent group branch modification, policies now account for protected branches configured for a group. This setting ensures that branches protected at the group level cannot be unprotected. Protected branches restrict certain actions, such as deleting the branch and force pushing to the branch. You can override this behavior and declare exceptions for specific top-level groups with the new approval_settings.block_group_branch_modification property to allow group owners to temporarily modify protected branches when necessary.
This new project override setting ensures that group protected branch settings cannot be modified to circumvent security and compliance requirements, ensuring more stable enforcement of protected branches.
Currently, only administrators can create service accounts on GitLab self-managed. Now, there is an optional setting which allows top-level group Owners to create service accounts. This allows administrators to choose if they would like a wider range of roles that are allowed to create service accounts, or keep it as an administrator-only task.
Service accounts now have a designated badge and can be easily identified in the users list. Previously, these accounts only had the bot badge, making it difficult to distinguish between them and group and project access tokens.
To give you more flexibility in designing your pipelines, you no longer
need to name your Pages deploy job pages. You can now simply use the
pages attribute in any CI/CD job to trigger a Pages deployment.
GitLab Duo Pro customers can now programmatically access AI Impact Analytics metrics with the aiMetrics GraphQL API. Metrics include the number of assigned GitLab Duo seats, Duo Chat users, and Code Suggestion users. The API also provides granular counts for code suggestions that are shown and accepted. With this data, you can calculate the acceptance rate for Code Suggestions, and better understand your Duo Pro users’ adoption of Duo Chat and Code Suggestions. You can also pair AI Impact Analytics metrics with Value Stream Analytics and DORA metrics to gain deeper insight into how adopting Duo Chat and Code Suggestions are impacting your team’s productivity.
You can now hide closed items from the linked and child items lists by turning off the Show closed items toggle. With this addition, you have greater control over your view and can focus on active work while reducing visual clutter in complex projects.
Prior to this release, it was not possible to get GitLab Duo Chat and Code Suggestions usage data per Duo Enterprise user. In 17.6, we’ve added a GraphQL API to provide visibility into the number of code suggestions accepted and Duo Chat interactions for each active Duo Enterprise user. The API can help you get more granular insight into who is using which Duo Enterprise features and how frequently. This is the first iteration toward our goal of providing more comprehensive Duo Enterprise usage data within GitLab.
The License Scanner now has the ability to consume a dependency’s license from a CycloneDX SBOM that includes supported package types.
In cases where the licenses field of a CycloneDX SBOM is available, users will see license data from their SBOM. In cases where the SBOM lacks license information we will continue to provide this data from our License database.
You can now create, test, and deploy applications for the newest generations of Apple devices using macOS Sequoia 15 and Xcode 16.
GitLab’s hosted runners on macOS help your development teams build and deploy macOS applications faster in a secure, on-demand build environment integrated with GitLab CI/CD.
Try it out today by using the macos-15-xcode-16 image in your .gitlab-ci.yml file.
You can now see JaCoCo test coverage results directly in your merge request diff view. This visualization allows you to quickly identify which lines are covered by tests and which need additional coverage before merging.
We’re also releasing GitLab Runner 17.6 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.
exec format error when installing the fleeting pluginFF_GIT_URLS_WITHOUT_TOKENS is enabledOn October 17, 2024, GitLab 17.5 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Jim was recognized for leading an effort to close nearly 100 backlog issues on GitLab. He is active in many of our weekly community pairing sessions that dive into some interesting discussions. Jim also supports people across the GitLab Community Discord, troubleshooting GitLab support requests and guiding new contributors. Jim works for an industrial technology company writing software for Critical Infrastructure and ERP systems.
“Even small contributions add up to make projects better,” says Jim. “Something as small as documentation contributions helps others out. You don’t have to champion a full new feature.”
Jim was nominated by Lee Tickett, Staff FullStack Engineer, Contributor Success at GitLab. “Issue triage/curation has been toward the top of my list to get the wider community involved in and Jim is paving the way here,” says Lee.
Daniel Murphy, Senior Program Manager, Contributor Success at GitLab, added to the nomination. “Jim’s outstanding support for new contributors and guidance in getting them started helps us grow as a community to co-create GitLab.”
“Impressive work on the merge request I reviewed!” says Vanessa Otto, Senior Frontend Engineer at GitLab. “Jim responded quickly, understood the suggestions immediately, and implemented them seamlessly. It was great to see such efficiency and clarity in Jim’s approach.”
We are so grateful to Jim and all of our open source community for contributing to GitLab!
Introducing Duo Quick Chat, an AI-powered chat designed to work exactly where you are in your code. Duo Quick Chat operates directly on the lines you’re editing, offering real-time assistance without ever moving you away from your code. Whether you’re refactoring, fixing bugs, or writing tests, Duo Quick Chat provides suggestions and explanations on the spot, ensuring that you stay fully focused without switching context.
You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for Code Suggestions. This feature is in beta and available with an Ultimate and Duo Enterprise subscription on self-managed GitLab environments.
With self-hosted models, you can use models hosted either on-premise or in a private cloud to enable GitLab Duo Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.
Please leave feedback in the feedback issue.
Previously, AI impact analytics were available only on GitLab.com to GitLab Duo Enterprise customers, and on GitLab self-managed with a ClickHouse integration. Additionally, the default metrics were aggregated.
Now, you can export raw code suggestion events from the GraphQL API. This way you can import the data into your data analysis tool to get deeper insights into acceptance rates across more dimensions, such as suggestion size, language, and user. The raw events are not stored in ClickHouse, so some AI Impact Analytics metrics become available to all GitLab deployments, including GitLab Dedicated and self-managed.
In response to your feedback, GitLab Duo Chat is now aware of merge requests. Whether you are a reviewer or an author, you can now converse with Chat about a merge request to quickly dig into it, or learn what to do next. Simply open your merge request and open Duo Chat, then start the conversation.
This new feature complements our existing feature, where you can quickly populate the description of a merge request by asking GitLab Duo to summarize code changes, so that reviewers can get a general understanding of what the merge request is about.
In GitLab 15.10, we introduced a consolidated view for branch-related settings and rules. This view provided you with an easy way to understand the configuration of your project across multiple settings.
Building on this feature, you can now directly modify specific branch rules in this view, including branch protections, approval rules, and external status check configurations. These new capabilities lay the foundation for continued improvements in branch configuration that will allow for greater flexibility in the future.
We encourage you to explore these new capabilities and to provide feedback. You can do this by contributing to our dedicated feedback issue.
Switchboard’s new Tenant Overview now provides a single place to quickly access essential information about your GitLab Dedicated instance.
With this first release, you can now view your current GitLab version, instance URL, and the date and time of your upcoming and past maintenance windows all on the Tenant Overview page.
We’re excited to announce that Secret Push Protection is now generally available for all GitLab Ultimate customers.
If a secret, like a key or an API token, is accidentally committed to a Git repository, anyone with access to the repository can impersonate the user of the secret for malicious purposes. A leaked secret costs time and money, and potentially damages a company’s reputation. Secret push protection helps reduce the remediation time and reduce risk by protecting secrets from being pushed in the first place.
Secret push protection has been improved since the beta release. When commits are pushed by using the Git CLI, now only the changes (diff) are scanned for secrets. We’ve also added experimental support for excluding paths, rules, or specific values to avoid false positives.
To learn more, see the blog.
The Credentials Inventory is now available for top-level group Owners on GitLab.com. In the Credentials Inventory, you can view your enterprise user’s personal access tokens and SSH keys across your group. You can also revoke, delete, and view additional information about the credentials. Previously, this was only available for administrators on GitLab self-managed.
Group Owners can use the Credentials Inventory to understand the credentials that exist in their purview, and provide increased visibility and control.
Now, in GitLab, you can filter for specific dependency components quickly to identify whether or not they are used in your group or project. It is time consuming and inconvenient to manually go through the entire list just to verify whether or not a particular package and version is present. With the new filter by component on the dependency list, you isolate vulnerable dependencies so that you can assess open risks in your application.
GitLab 17.5 includes an update to our version of the NGINX Ingress Controller. The nginx-controller container image is now version 1.11.2. Please
note this includes new RBAC requirements because the new controller now uses endpointslices and requires an RBAC rule to access them.
GitLab 17.5 includes support for upgrading PostgreSQL from version 14.x to 16.x for single node installations. Automatic upgrades are not enabled and so PostgreSQL upgrades must be triggered manually.
Empower your development workflow with Duo Chat, now seamlessly integrated into Visual Studio for Windows. Duo Chat enhances your coding experience by providing AI-powered capabilities to explain, refine, debug code, or write tests all in real-time. This integration allows you to leverage Duo Chat’s advanced AI tools directly within your familiar development environment, improving productivity and enabling faster, more efficient problem-solving.
You can check the status of your pods and Flux reconciliation from the GitLab environments UI. However, this approach is hard to scale because the required settings are exposed only through GraphQL or the UI. Now, GitLab ships with REST API support for configuring an agent for Kubernetes, as well as setting the namespace and Flux resource per environment. To further improve support for dynamic environments, issue 467912 proposes adding support for configuring these settings in CI/CD pipelines.
GitLab offers flexible, reliable, and secure GitOps support with the agent for Kubernetes and its Flux integration.
Still, bootstrapping Flux with GitLab and setting up the agent for Kubernetes used to require a lot of documentation reading and switching between the GitLab UI and the terminal.
The GitLab CLI now offers the glab cluster agent bootstrap command to simplify installing the agent on top of an existing Flux installation.
Now, you can configure Flux and the agent with just two simple commands.
Until now, the agent for Kubernetes could be used only if the Kubernetes cluster could connect to the GitLab instance.
This issue meant that some customers couldn’t use the agent if, for example, they ran GitLab on a private network or behind a firewall.
From GitLab 17.5, you can initiate the cluster-GitLab connection from GitLab, assuming that a properly configured agentk instance is already waiting for a connection initialization.
Once the initial connection is established, all the features of the agent are available. Initializing from a cluster is not changed with this development.
GitLab provides a real-time view of your pods, as well as pod log streaming, all through the dashboard for Kubernetes. In GitLab 17.4, we offered a static listing of resource-specific event information from the UI. This release further improves the dashboard for Kubernetes by letting you stream incoming events as they emerge in the cluster.
As a Flux user, have you ever needed to quickly stop an automatic reconciliation or drift remediation? Have you wanted to trigger a HelmRelease to synchronize manually removed resources? These actions are best achieved with the Flux suspend and resume functions. Until now, your best option was to use the Flux CLI, which required a context switch and several commands to ensure the right resource was affected. In GitLab 17.5, you can suspend or resume a reconciliation from the built-in dashboard for Kubernetes.
Administrators now have an enhanced, summarized view of the following critical pieces of information about the users on their instance:
This increases user management efficiency, because administrators can quickly see how many users are in these states from the summary view, and filter on them.
You can now target groups/subgroups in security policy scopes. This extends the existing options allowing you to target all projects in a group/subgroup, projects based on a defined project list, and projects matching a list of compliance framework labels.
This gives you further flexibility in enabling policies across your groups, while also being able to apply exceptions to scope projects out of enforcement where necessary.
This improvement also precedes a number of enhancements that will simplify the process of linking security policy projects and granularly scoping enforcement of policies.
Enterprise users can authenticate using a local account with username and password. Now, group Owners can disable password authentication for the group’s enterprise users. If password authentication is disabled, enterprise users can use either the group’s SAML identity provider to authenticate with GitLab web UI, or a personal access token to authenticate with GitLab API and Git using HTTP Basic Authentication.
Previously, the compliance center was available only for top-level groups and subgroups.
With this release, we’ve added the compliance center to projects. At this level, compliance center provides view-only capabilities for checks and violations that pertain to a particular project.
To add or edit a framework, you should access the compliance center on top-level groups instead.
In GitLab 17.3, we announced the deprecation of compliance pipelines and its eventual removal by the 18.0 release. Instead of compliance pipelines, you should use the pipeline execution policy type instead, which was released in GitLab 17.2.
To help you migrate your existing compliance pipelines over to the pipeline execution policy type, this release includes a warning banner that:
You can now view which groups, subgroups, and projects a token is associated with. This makes it easier to determine the impact of token expirations or revocations, and to understand where a token is able to be used.
Previously, when SAML SSO was enabled, groups could choose to enforce SSO, which required all members to use SSO authentication to access the group. However, some groups want the security of SSO enforcement for employees or group members, while still allowing outside collaborators or contractors to access their groups without SSO.
Now, groups with SAML SSO enabled have SSO automatically enforced for all members who have a SAML identity. Group members without SAML identities are not required to use SSO unless SSO enforcement is explicitly enabled.
A member has a SAML identity if one or both of the following are true:
To ensure smooth operation of the selective SSO enforcement feature, ensure your SAML configuration is working properly before selecting the Enable SAML authentication for this group checkbox.
We’re excited to announce a significant improvement to our Container Registry API for self-managed GitLab instances. With the release of GitLab 17.5, we’ve implemented keyset pagination for the :id/registry/repositories/:repository_id/tags endpoint, bringing it in line with the functionality already available on GitLab.com. This enhancement is part of our ongoing efforts to improve API performance and provide a consistent experience across all GitLab deployments.
Keyset pagination offers a more efficient method for handling large datasets, resulting in improved performance and a better user experience. This update is particularly useful when managing large container registries, as it allows for smoother navigation through repository tags. In order to use this feature, self-managed instances must upgrade to the next-generation container registry.
We’re thrilled to introduce support for protected npm packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.
From GitLab 17.5, you can protect npm packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.
We’ve added Ruby support to GitLab Advanced SAST. To use this new cross-file, cross-function scanning support, enable Advanced SAST. If you’ve already enabled Advanced SAST, Ruby support is automatically activated.
In the last month, we’ve also released updates to improve the detection rules for the other languages Advanced SAST supports by:
To see which types of vulnerabilities Advanced SAST detects in each language, see the new Advanced SAST coverage page.
To learn more about Advanced SAST, see last month’s announcement blog.
We’re also releasing GitLab Runner 17.5 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.
gitlab-runner-fips-17.4.0-1 package fails to run on Amazon Linux 2 and returns a glibc errorDOCKER_AUTH_CONFIG variable has multiple registriesOn September 19, 2024, GitLab 17.4 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Archish Thakkar is one of GitLab’s top contributors this year with 46 closed issues and 119 merged MRs. These contributions have helped Archish earn top spots in the last two GitLab Hackathons. He is a Senior Software Engineer at Middleware and passionate open source contributor.
Archish was nominated by Peter Leitzen, Staff Backend Engineer, Engineering Productivity at GitLab. The nomination was supported by Max Woolf, Staff Backend Engineer at GitLab, and James Nutt, Senior Backend Engineer at GitLab. Archish’s contributions have increased in the past two months where he has consistently demonstrated outstanding commitment to improving GitLab’s codebase, contributing multiple QoL (Quality of Life) fixes and reducing technical debt.
Many thanks to Archish and the rest of GitLab’s open source contributors for co-creating GitLab!
Elevate your coding workflow and receive more context-aware Code Suggestions using the contents of other open tabs.
This improvement to Code Suggestions now uses the content of your open editor tabs to provide more relevant and accurate code recommendations.
Merge requests have many required checks that must pass before they are mergeable. These checks can include approvals, unresolved threads, pipelines, and other items that need to be satisfied. When you’re responsible for merging code, it can be hard to keep track of all of these events, and know when to come back and check to see if a merge request can be merged.
GitLab now supports Auto-merge for all checks in merge requests. Auto-merge enables any user who is eligible to merge to set a merge request to Auto-merge, even before all the required checks have passed. As the merge request continues through its lifecycle, the merge request automagically merges after the last failing check passes.
We’re really excited about this improvement to accelerate your merge request workflows. You can leave feedback about this feature in issue 438395.
We’re thrilled to announce the launch of the extension marketplace in the Web IDE on GitLab.com. With the extension marketplace, you can discover, install, and manage third-party extensions and enhance your development experience. Some extensions are not compatible with the web-only version because they require a local runtime environment. However, you can still choose from thousands of extensions to boost your productivity or customize your workflow.
The extension marketplace is disabled by default. To get started, you can enable the extension marketplace in the Integrations section of your user preferences. For enterprise users, only users with the Owner role for a top-level group can enable the extension marketplace.
You can now configure sudo access for your workspace, making it easier than ever to install, configure, and run dependencies directly in your development environment. We’ve implemented three secure methods to ensure a seamless development experience:
With this feature, you can fully customize your environment to match your workflow and project needs.
GitLab provides a real-time view into your pods and streaming pod logs. Until now, however, we didn’t show you resource-specific event information from the UI, so you still had to use 3rd party tools to debug Kubernetes deployments. This release adds events to the resource details view of the dashboard for Kubernetes.
This is the first time we’ve added events to the UI. Currently, events are refreshed every time you open the resource details view. You can track the development of real-time event streaming in issue 470042.
Previously, to create a GitLab Pages project, you needed a domain formatted like name.example.io
or name.pages.example.io. This requirement meant you had to set up wildcard DNS records and
TLS certificate. In this release, setting up a GitLab Pages project without a DNS wildcard has
moved from beta to generally available.
Removing the requirement for wildcard certificates eases administrative overhead associated with GitLab Pages. Some customers can’t use GitLab Pages because of organizational restrictions on wildcard DNS records or certificates.
This release introduces Pages parallel deployments in beta. You can now easily preview changes and manage parallel deployments for your GitLab Pages sites. This enhancement allows for seamless experimentation with new ideas, so you can test and refine your sites with confidence. By catching any issues early, you can ensure that the live site remains stable and polished, building on the already great foundation of GitLab Pages.
Additionally, parallel deployments can be useful for localization when you deploy different language versions of an application or website.
Getting up to speed on lengthy issue discussions can be a significant time investment. With this release, AI-generated issue discussion summarization has been integrated with Duo Chat and is now generally available for GitLab.com, Self-managed, and Dedicated customers.
We’re excited to announce that our Advanced Static Application Security Testing (SAST) scanner is now generally available for all GitLab Ultimate customers.
Advanced SAST is a new scanner powered by the technology we acquired from Oxeye earlier this year. It uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities in first-party code. It delivers more accurate results so developers and security teams don’t have to sort through the noise of false-positive results.
Along with the new scanning engine, GitLab 17.4 includes:
To learn more, see the announcement blog.
You might not want anyone to see the value of a variable after it is saved to project settings. You can now select the new Masked and hidden visibility option when creating a CI/CD variable. Selecting this option will permanently mask the value of the variable in the CI/CD settings UI, restricting the value from being displayed to anyone in the future and decreasing visibility of your data.
GitLab 17.4 includes PostgreSQL 16 by default for fresh installations of GitLab.
GitLab 17.7 will include OpenSSL V3. This will affect Omnibus instances with external integration setup’s that do not meet the minimum requirements of TLS 1.2 or above for outbound connections, along with at least 112-bit encryption for TLS certificates. Please review our OpenSSL upgrade documentation for more information or if your are unsure if your instance will be affected.
We added new endpoints to the Groups API and Projects API to retrieve the groups that have been invited to a group or project. This functionality is available only on the Members page of a group or project. We hope that this addition will make it easier to automate membership management for your groups and projects. The endpoints are rate-limited to 60 requests per minute per user.
Previously, you could only add domain restrictions at the group level in the UI. Now, you can also do this by using the new allowed_email_domains_list attribute in the Groups API.
We have simplified the display of the source column on the Members page for groups and projects. Direct members are still indicated as Direct member. Inherited members are now listed as Inherited from followed by the group name. Members that were added by inviting a group to the group or project are listed as Invited group followed by the group name. For members that inherited from an invited group that was added to a parent group, we now display the last step to keep the display actionable for users managing membership.
Users on self-managed instances will now receive an email when they are assigned a GitLab Duo seat. Previously, you wouldn’t know you were assigned a seat unless someone told you, or you noticed new functionality in the GitLab UI.
To disable this email, an administrator can disable the duo_seat_assignment_email_for_sm feature flag.
Previously, GitLab provided the ability to resend webhook requests only in the UI, which was inefficient if many requests failed.
So that you can handle failed webhook requests programmatically, in this release thanks to a community contribution, we added API endpoints for resending them:
You can now:
id of any event to resend it.Thanks to Phawin for this community contribution!
From this release, we support an idempotency key in the headers of webhook requests. An idempotency key is a unique ID that remains consistent across webhook retries, which
allows webhook clients to detect retries. Use the Idempotency-Key header to ensure the idempotency of webhook effects on integrations.
Thanks to Van for this community contribution!
Code intelligence in GitLab provides code navigation features when browsing a repository. Getting started with code navigation is often complicated, as you must configure a CI/CD job. This job can require custom scripting to provide the correct output and artifacts.
GitLab now supports an official Code intelligence CI/CD component for easier setup. Add this component to your project by following the instructions for using a component. This greatly simplifies adopting code intelligence in GitLab.
Currently, the component supports these languages:
We’ll continue to evaluate available SCIP indexers as we look to broaden language support for the new component. If you’re interested in adding support for a language, please open a merge request in the code intelligence component project.
When you share a link to a specific file in a merge request, it’s often because you want the person to look at something within that file. Merge requests previously needed to load all of the files before scrolling to the specific position you’ve referenced. Linking directly to a file is a great way to improve the speed of collaboration in merge requests:
Feedback about linked files can be left in issue 439582.
Our GitLab Duo plugin for JetBrains now offers a more secure and streamlined onboarding process. Sign in quickly and securely with OAuth. It integrates seamlessly with your existing workflow, with no personal access token required!
Due to an implementation issue, the action: prepare, action: verify, and action: access jobs
become manual jobs when they run against a protected environment. These jobs require manual interaction to run,
although they don’t require any additional approvals.
Issue 390025 proposes to fix the implementation, so these jobs won’t be turned into manual jobs. After this proposed change, to keep the current behavior, you will need to explicitly set the jobs to manual.
For now, you can change to the new implementation now by enabling the prevent_blocking_non_deployment_jobs feature flag.
Any proposed breaking changes are intended to differentiate the behavior of the
environment.action: prepare | verify | access values.
The environment.action: access keyword will remain the closest to its current behavior.
To prevent future compatibility issues, you should review your use of these keywords now. You can learn more about these proposed changes in the following issues:
Although you can configure Flux to trigger reconciliations at specified intervals, there are situations where you might want an immediate reconciliation. In past releases, you could trigger the reconciliation from a CI/CD pipeline or from the command line. In GitLab 17.4, you can now trigger a reconciliation from a dashboard for Kubernetes with no additional configuration.
To trigger a reconciliation, go to a configured dashboard and select the Flux status badge.
Administrators can now decide if they want to enforce a mandatory expiration date for personal, project, and group access tokens. If administrators disable this setting, any new access token generated will not be required to have an expiration date. By default this setting is enabled, and an expiration less than that of the maximum allowed lifetime is required. This setting is available in GitLab 16.11 and later.
In GitLab 17.3, we provided users with the ability to add multiple compliance frameworks to a project.
Now you can search by multiple compliance frameworks, which makes it easier to search for projects that have multiple compliance frameworks attached to them.
In GitLab 17.4, we added a setting to security policies you can use to grant read access to pipeline-execution.yml files for all linked projects. This setting gives you more flexibility to enable users, bots, or tokens that enforce pipeline execution globally across projects. For example, you can ensure a group or project access tokens can read security policy configurations in order to trigger pipelines during pipeline execution. You still can’t view the security policy project repository or YAML directly. The configuration is used only during pipeline creation.
To configure the setting, go to the security policy project you want to share. Select Settings > General > Visibility, project features, permissions, scroll to Pipeline execution policies, and enable the Grant access to this repository for projects linked to it as the security policy project source for security policies toggle.
An enhancement to the 17.2 release of pipeline execution policies, policy creators may now configure pipeline execution policies to handle collisions in job names gracefully. With the policy.yml for the pipeline execution policy, you may now configure the following options:
suffix: on_conflict configures the policy to gracefully handle collisions by renaming policy jobs, which is the new default behaviorsuffix: never enforces all jobs names are unique and will fail pipelines if collisions occur, which has been the default behavior since 17.2With this improvement, you can ensure security and compliance jobs executed within a pipeline execution policy always run, while also preventing unnecessary impacts to developers downstream.
In a follow-up enhancement, we will introduce the configuration option within the policy editor.
You can now adjust the wiki sidebar to see longer page titles, improving the overall discoverability of content. As wiki content grows, having a resizable sidebar helps manage and browse through complex hierarchies or extensive lists of pages more efficiently.
GitLab 15.3 added support for ingesting CycloneDX SBOMs.
In GitLab 17.4 we have added support for ingesting CycloneDX version 1.6 SBOMs.
Fields relating to hardware (HBOM), services (SaaSBOM), and AI/ML models (AI/ML-BOM) are not currently supported. SBOMs that contain data relating to these BOMs will be processed, but the data will not be analyzed or presented to users. Support for these other BOM-types is being tracked in this epic.
In GitLab 17.0, 16.0, and 15.4, we streamlined GitLab SAST so it uses fewer separate analyzers to scan your code for vulnerabilities.
Now, after you upgrade to GitLab 17.3.1 or later, a one-time data migration will automatically resolve leftover vulnerabilities from the analyzers that have reached End of Support. This helps clean up your Vulnerability Report so you can focus on the vulnerabilities that are still detected by the most up-to-date analyzers.
The migration only resolves vulnerabilities that you haven’t confirmed or dismissed, and it doesn’t affect vulnerabilities that were automatically translated to Semgrep-based scanning.
Both pipeline and client-side Secret Detection now support detection of Anthropic API keys.
You can now use JaCoCo coverage reports, a popular standard for coverage calculation, inside your merge requests. The feature is available as beta, but ready for testing by anyone who wants to use JaCoCo coverage reports right away. If you have any feedback, feel free to contribute to the feedback issue.
We’re also releasing GitLab Runner 17.4 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On August 15, 2024, GitLab 17.3 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Anton Kalmykov is one of GitLab’s top contributors this year with 37 merged contributions since February and more in progress. Anton is a Senior Frontend Engineer at Yolo group (Bombay Games).
“Contributing to GitLab is one of the most challenging, ambitious, and exciting initiatives,” says Anton. “I appreciate the opportunity to be involved in creating and improving such a great product. Thanks to this chance, I have learned a lot of new things, and I still have a lot to do. I am incredibly grateful to the GitLab team, especially those who have checked my MRs, guided me, and helped me do things right.”
Anton was nominated by Christina Lohr, Senior Product Manager at GitLab, for helping out the Tenant Scale group with several frontend issues.
“We have a lot of smaller UX improvements to work through for our basic workflows, and it is great to get help from the community to complete these initiatives faster,” says Christina. “All these improvements are helping to create a more cohesive user experience between groups and projects. Thank you Anton.”
Many thanks to Anton and the rest of GitLab’s open source contributors for co-creating GitLab!
Root cause analysis is now generally available. With root cause analysis, you can troubleshoot failed jobs in CI/CD pipelines faster. This AI-powered feature analyzes the failed job log, quickly determines the root cause of the job failure, and suggests a fix for you.
You can now troubleshoot the setup for GitLab Duo on your self-managed instance. In the Admin area, on the GitLab Duo page, select Run health check. This health check performs a series of validations and suggests appropriate corrective actions to ensure GitLab Duo is operational.
The health check for GitLab Duo is available on Self-managed and GitLab Dedicated as a beta feature.
Have you ever needed to restart or delete a failing pod in Kubernetes? Until now, you had to leave GitLab, use another tool to connect to the cluster, stop the pod, and wait for a new pod to start. GitLab now has built-in support for deleting pods, so you can smoothly troubleshoot your Kubernetes clusters.
You can stop a pod from a dashboard for Kubernetes, which lists all the pods across your cluster or namespace.
Do you want to connect to a Kubernetes cluster from your local terminal or using one of the desktop Kubernetes GUI tools? GitLab allows you to connect to a terminal using the user access feature of the agent for Kubernetes. Previously, finding commands required navigating out of GitLab to browse the documentation. Now, GitLab provides the connect command from the UI. GitLab can even help you configure user access!
To retrieve the connection command, either go to a Kubernetes dashboard, or to the agent list.
Vulnerability resolution uses AI to give specific code suggestions for users to fix vulnerabilities. With the click of a button you can open a merge request to get started resolving any SAST vulnerability from the list of supported CWE identifiers.
You can create a compliance framework to identify that your project has certain compliance requirements or needs additional oversight. The compliance framework can optionally enforce compliance pipeline configuration to the projects on which it is applied.
Previously, users could only apply one compliance framework to a project, which limited how many compliance requirements could be set on a project. We have now provided the ability for a user to apply multiple compliance frameworks per project. This will allow users to apply multiple different compliance frameworks onto a single project at a given time. With this release, you can apply multiple compliance frameworks to a project. The project is then set with the compliance requirements of each framework.
These two new metrics highlight the effectiveness and utilization of GitLab Duo, and are now included in the AI Impact analytics in the Value Streams Dashboard, which helps organizations understand the impact of GitLab Duo on delivering business value.
The Code Suggestions acceptance rate metric indicates how frequently developers accept code suggestions made by GitLab Duo. This metric reflects both the effectiveness of these suggestions and the level of trust contributors have in AI capabilities. Specifically, the metric represents the percentage of code suggestions provided by GitLab Duo that have been accepted by code contributors in the last 30 days.
The GitLab Duo seats assigned and used metric shows the percentage of consumed licensed seats, helping organizations plan effectively for license utilization, resource allocation, and understanding of usage patterns. This metric tracks the ratio of assigned seats that have used at least one AI feature in the last 30 days.
With the addition of these new metrics, we have also introduced new overview tiles — a new visualization which provides a clear summary of the metrics, helping you quickly assess the current state of your AI features.
GitLab 17.3 includes packages for supporting Raspberry Pi OS 12.
Debian 10 has reached EOL on June 30th, 2024. GitLab will remove support for Debian 10 in GitLab 17.6.
We have updated the sorting and filtering functionality of the project and group overview in Your Work. Previously, in the Your Work page for projects, you could filter by name and language, and use a pre-defined set of sorting options. We have standardized the sorting options to include Name, Created date, Updated date, and Stars. We also added a navigation element to sort in ascending or descending order, and moved the language filter to the filter menu. Now you can find archived projects in the new Inactive tab. Additionally, we added a Role filter that allows you to search for projects you are the Owner of.
In the Your Work page for groups, we have standardized the sorting options to include Name, Created date, and Updated date, and added a navigation element to sort in ascending or descending order.
We welcome feedback about these changes in #438322.
When you enable advanced search in GitLab, you can now select Index the instance to perform initial indexing or re-create an index from scratch. This setting achieves functional parity with the gitlab:elastic:index rake task by indexing all supported types of data into the integrated Elasticsearch or OpenSearch cluster.
Index the instance replaces the setting to index all projects, which was limited to the initial indexing only.
Until now, you could only control whether a project inherited integration settings, or used its own settings, using the UI.
In this milestone, we are introducing a new use_inherited_settings parameter to the REST API of all integrations. This parameter allows you to use the API to set
whether or not a project inherits integration settings. If not set, the default behavior is false (use the project’s own settings).
Since GitLab 9.3 you can view project webhook request history in the UI, and since GitLab 15.3 you can also view group webhook request history in the UI.
In this release, that data is now exposed in the REST API, which can help you automate processes to discover and respond to webhook errors. You can get a list of events for a specific project hook and group hook in the past 7 days.
Thanks to Phawin for this community contribution!
In 17.2, we added the ability to search for project settings by using the command palette. This change made it easier to quickly find the settings you need.
With 17.3, you can now search for group settings from the command palette as well. Try it out by visiting a group, selecting Search or go to, entering command mode with >, and typing the name of a settings section, like Merge request approvals. Select a result to jump right to the setting itself.
Get more control over your coding experience in VS Code by enabling or disabling code suggestions for specific programming languages. This granular control allows you to customize your workflow, reducing irrelevant or intrusive suggestions while maintaining the benefits of code suggestions for your preferred languages.
For tighter security in sensitive environments, you can now configure custom HTTP agent options, including client certificates and certificate authorities, directly in your JetBrains IDE settings.
Currently, the process for removing content from a repository is complicated, and you might have to force push the project to GitLab. This is prone to errors and can cause you to temporarily turn off protections to enable the push. It can be even harder to delete files that use too much space within the repository.
You can now use the new repository maintenance option in project settings to remove blobs based on a list of object IDs. With this new method, you can selectively remove content without the need to force push a project back to GitLab.
In the event that secrets or other content has been pushed that needs to be redacted from a project, we’re also introducing a new option to redact text.
Provide a string that GitLab will replace with ***REMOVED*** in files across the project.
After the text has been redacted, run housekeeping to remove old versions of the string.
This new UI streamlines the way you can manage your repositories when content needs to be removed.
Because the agent for Kubernetes allows bi-directional data flow between a Kubernetes cluster and GitLab, it’s important to know when a component that can access your systems is added or removed. In past releases, compliance teams had to use custom tooling or search for this data in GitLab directly. GitLab now provides the following audit events:
cluster_agent_created records who registered a new agent for Kubernetes.cluster_agent_create_failed records who tried to register a new agent for Kubernetes but failed.cluster_agent_deleted records who removed an agent for Kubernetes registration.cluster_agent_delete_failed records who tried to remove an agent for Kubernetes registration but failed.These audit events extend the cluster_agent_token_created and cluster_agent_token_revoked audit events to further improve the ability to audit your GitLab instance.
This release adds full support for Kubernetes version 1.30, released in April 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
External status checks can now be configured with HMAC (Hash-based Message Authentication Code) authentication. This will provide a more secure way to verify the authenticity of requests from GitLab to external services.
When enabled for your status check, a shared secret is used to generate a unique signature for each request. The signature is sent in the X-Gitlab-Signature header, using SHA256 as the hash algorithm.
In a future iteration, GitLab plans to add an option to also verify and block HTTP requests.
Users can now filter the Members page by role. Use the filter to find members with a specific role.
Previously, if you wanted to view permissions for the custom roles of a user, you had to have the Owner role in the group. This requirement made it difficult to troubleshoot and understand what actions a user can perform when assigned a custom role. Now, any user can view the permissions of a user assigned a custom role in the Members page.
Organizations that use LDAP group links to manage user permissions for groups can already use default roles for membership.
In this release, we’re extending that support to custom roles. This configuration makes it easier to map access to a large group of users.
You can create custom roles with the following new permission:
With custom roles, you can reduce the number of users with the Owner role by creating users with equivalent permissions. This helps you define roles that are tailored to the needs of your group, and prevents users from being given more privileges than they need.
Administrators can now disable or re-enable instance personal access tokens through the Admin UI. Previously, administrators had to use the application settings API or the GitLab Rails console to do this.
You can now add your Bluesky did:plc identifier to your GitLab profile.
Thank you Dominique for your contribution!
GitLab’s sign out process has been improved so that cookies from sibling subdomains are not deleted on sign out. Previously, these cookies were deleted, causing users to be signed out of other subdomain services on the same top-level domain as GitLab. For example, if a user has Kibana set up on kibana.example.com and GitLab set up on gitlab.example.com, signing out from GitLab will no longer sign the user out from Kibana.
Thank you Guilherme C. Souza for your contribution!
We are excited to announce a significant improvement to our AI Impact analytics with the introduction of sparklines. These small, simple graphs embedded in data tables enhance the readability and accessibility of AI Impact data. By transforming numerical values into visual representations, the new sparklines make it easier to identify trends over time, so you can spot upward or downward movements. This new visual approach also streamlines the process of comparing trends across multiple metrics, reducing the time and effort required when relying solely on numbers.
Tasks are frequently used to break down issues into engineering implementation steps. Before this release, there was no way to connect a merge request to a task it implements. You can now use the same closing pattern that you would when referencing issues from a merge request description to connect a merge request to a task. From the task view, connected merge requests are visible from the sidebar. If your project has the auto-close setting enabled, the task will automatically close when the connected merge request is merged into your default branch.
You can now effortlessly update parent assignments for OKRs and tasks, directly from the child record, eliminating the need to navigate back and forth. This is a great step towards our goal of improving efficiency with your workflows.
You can now easily report abuse for work items directly from the Actions menu, just like you can with legacy issues. This new feature helps keep your workspace clean and safe by allowing you to quickly flag inappropriate content, ensuring a better collaborative environment for your team.
You can now resolve threads in tasks, objectives, and key results, making it easier to manage and track important conversations. Resolved threads are collapsed by default, helping you focus on active discussions and streamline your collaboration workflows.
To improve the tracking of merge request (MR) review time in GitLab, we added a new stage event to Value Stream Analytics: MR first reviewer assigned. With this new event teams can identify where delays occur in the review process, find opportunities to improve collaboration, and encourage a culture of responsiveness and accountability among team members. Reducing the review time directly impacts the overall cycle time of development, leading to faster software delivery. For example, you can now add a new custom Review Time to Merge (RTTM) stage that starts with MR first reviewer assigned and ends with MR merged.
Composition Analysis has delivered Rust support for Dependency and License Scanning. Rust scanning supports the Cargo.lock file type.
To enable Rust scanning for your Project use the cargo template from the Dependency Scanning CI/CD Component.
GitLab 15.3 added support for ingesting CycloneDX SBOMs. While the SBOM reports are validated against the CycloneDX schema, any warnings and errors produced as part of validation were not displayed to the user.
In GitLab 17.3 these validation messages appear in the GitLab UI on the project-level Vulnerability Report and Dependency List pages.
Users will be able to view SBOM ingestion errors in the following areas of the GitLab UI: the project level vulnerability report and dependency list pages, the licenses and security tabs of the pipeline page.
You can customize the rules used in SAST, IaC Scanning, and Secret Detection by creating a local configuration file committed in the repository or by setting a CI/CD variable to apply a shared configuration across multiple projects.
Previously, scanners preferred the local configuration file, even if you also set a shared ruleset reference. This precedence order made it difficult to ensure that scans would use a known, trusted ruleset.
Now, we’ve added a new CI/CD variable, SECURE_ENABLE_LOCAL_CONFIGURATION, to control whether local configuration files are allowed.
It defaults to true, which keeps the existing behavior: local configuration files are allowed and are preferred over shared configurations.
If you set the value to false when you enforce scan execution, you can be sure that scans use your shared ruleset, or the default ruleset, even if project developers add a local configuration file.
You can now quickly find a specific job by searching for a job name.
Previously, you could only filter the list of jobs by status, requiring manual scrolling to find a specific job. With this release, you can now enter a job name to filter the results. The results will only include jobs in pipelines that ran after the release of GitLab 17.3.
You can now visualize the merge train to gain better insight into the status and order of merge requests in the pipeline. With merge train visualization, you can identify conflicts earlier, take actions on merge requests directly in the merge train, and minimize the risk of breaking the default branch.
We’re releasing GitLab Runner 17.3 today! GitLab Runner is the lightweight, highly scalable 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.
For a list of all changes, see the GitLab Runner changelog.
We have shipped performance improvements with the recent upgrade to macOS 14.5 and Xcode 15.4. With this change, Xcode build jobs are significantly faster compared to previous job executions.
The details page for a CI/CD component in the catalog provides useful information about the component. In this release we’ve added two more columns to the table that shows information about available inputs. The new Description and Type columns make it much easier to understand what an input is used for, and what type of value is expected.
On July 18, 2024, GitLab 17.2 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Phawin Khongkhasawan is a Tech Lead at Jitta and started contributing to GitLab in February of 2024. In just a few months, Phawin has merged over 20 contributions and his contributions have also been featured in 16.11, 17.0, and 17.1.
Phawin was first nominated by Magdalena Frankiewicz, Product Manager at GitLab, for improving Webhook related features like the request to Allow triggering of project test webhooks via the API. GitLab engineers Marc Shaw and Jose Ivan Vargas, and GitLab Product Manager Rutvik Shah, highlighted Phawin’s patience in collaboration and iteration, two of GitLab’s core values.
“I really appreciate Phawin’s work, patience and perseverance on pushing the feature to Add order by merged_at to the finish line,” says Patrick Bajao, Staff Backend Engineer at GitLab. “It took a couple of milestones before it got merged and deployed, but he didn’t stop and he continued to collaborate with us.”
A big thank you to Phawin for showing how new contributors can make an immediate impact and help co-create GitLab.
In GitLab 16.1, we introduced the Kubernetes pod list and detail views. However, you still had to use third-party tools for an in-depth analysis of your workloads. GitLab now ships with a log streaming view for pods and containers, so you can quickly check and troubleshoot issues across your environments without leaving your application delivery tool.
GitLab is now disabling AI input and output logging for GitLab Duo by default.
At GitLab, we aim to ensure that customers have sovereignty over their data. We’ve now disabled input and output logging by default and will only log inputs and outputs with customers’ explicit consent via a GitLab Support ticket.
When you perform a review, you can complete it by choosing whether to approve, comment, or request changes (released in GitLab 16.9). While reviewing, you might find changes that should prevent a merge request from merging until they’re resolved, and so you complete your review with request changes.
When requesting changes, GitLab now adds a merge check that prevents merging until the request for changes has been resolved. The request for changes can be resolved when the original user who requested changes re-reviews the merge request and subsequently approves the merge request. If the user who originally requested changes is unable to approve, the request for changes can be Bypassed by anyone with merge permissions, so development can continue.
Leave us feedback about this new feature in issue 455339.
Vulnerability Explanation is now a part of GitLab Duo Chat and is generally available. With Vulnerability Explanation, you can open chat from any SAST vulnerability to better understand the vulnerability, see how it could be exploited, and review a potential fix.
GitLab now supports the OAuth 2.0 device authorization grant flow. This flow makes it possible to securely authenticate your GitLab identity from input constrained devices where browser interactions are not an option. This makes the device authorization grant flow ideal for users attempting to use GitLab services from headless servers or other devices with no, or limited, UI. Thank you John Parent for your contribution!
The pipeline execution policy type is a new type of security policy that allows users to support enforcement of generic CI jobs, scripts, and instructions.
The pipeline execution policy type enables security and compliance teams to enforce customized GitLab security scanning templates, GitLab or partner-supported CI templates, 3rd party security scanning templates, custom reporting rules through CI jobs, or custom scripts/rules through GitLab CI.
The pipeline execution policy has two modes: inject and override. The inject mode injects jobs into the project’s CI/CD pipeline. The override mode replaces the project’s CI/CD pipeline configuration.
As with all GitLab policies, enforcement can be managed centrally by designated security and compliance team members who create and manage the policies. Learn how to get started by creating your first pipeline execution policy!
We have expanded support of custom rulesets in pipeline secret detection.
You can use two new types of passthroughs, git and url, to configure remote rulesets. This makes it easier to manage workflows such as sharing ruleset configurations across multiple projects.
You can also extend the default configuration with a remote ruleset by using one of those new types of passthroughs.
The analyzer also now supports:
GitLab Duo Chat and Code Suggestions are now available in workspaces! Whether you’re seeking quick answers or efficient code improvements, Duo Chat and Code Suggestions are designed to boost productivity and streamline your workflow, making remote development in workspaces more efficient and effective than ever.
We have updated the sorting and filtering functionality of the group overview page. The search element now stretches across the whole page, allowing you to see your search strings better. We have standardized the sorting options to Name, Created date, Updated date, and Stars.
We welcome feedback about these changes in issue 438322.
We added a new endpoint to the Groups API to list the groups a group has been invited to. This functionality complements the endpoint to list the projects that a group has been invited to, so you can now get a complete overview of all the groups and projects that your group has been added to. The endpoint is rate-limited to 60 requests per minute per user.
Thank you @imskr for this community contribution!
Discussions on GitLab issues can get busy. GitLab helps you manage these conversations by raising a to-do item for comments that are relevant to you, and automatically resolves the item when you take an action on the issue.
Previously, when you took action on a thread in the issue, all to-do items were resolved, even if you were mentioned in several different threads. Now, GitLab resolves only the to-do item for the thread you interacted with.
You can import projects to GitLab from other SCM solutions. However, it was difficult to know if project items were imported or created on the GitLab instance.
With this release, we’ve added visual indicators to items imported from GitHub, Gitea, Bitbucket Server, and Bitbucket Cloud where the creator is identified as a specific user. For example, merge requests, issues, and notes.
Previously, when using GitLab for Jira Cloud app, if you deleted a branch in GitLab, that branch still
appeared in Jira development panel. Selecting that branch caused a 404 error on GitLab.
From this release, branches deleted in GitLab are removed from the Jira development panel.
GitLab offers many settings across projects, groups, the instance, and for yourself personally. To find the setting you’re looking for, you often have to spend time clicking through many different areas of the UI.
With this release, you can now search for project settings from the command palette. Try it out by visiting a project, selecting Search or go to…, entering command mode with >, and typing the name of a settings section, like Protected tags. Select a result to jump right to the setting itself.
Crafting commit messages is an important part of ensuring that future users understand what and why changes were made to the codebase. It’s challenging to come up with a message that communicates your changes effectively and takes into account everything you might have changed.
Generation of merge commits with GitLab Duo is now Generally Available to help ensure every merge request has quality commit messages. Before you merge, select Edit commit message in the merge widget, then use the Generate commit message option to have a commit message drafted.
This new GitLab Duo capability is a great way to make sure your project’s commit history is a valuable resource for future developers.
GitLab Duo for the CLI is now generally available for all users. You can now ask GitLab Duo to help you with finding the right git command for your need.
Use glab duo ask <git question> to have GitLab Duo provide you with formatted git commands to achieve your goals. The GitLab CLI then provides additional details on the commands and what they will do, including information on any flags being passed. You’re then able to run the commands and get their output directly in your workflow.
The ask command for the GitLab CLI is a great way to speed up your workflow with git commands you need a little extra help remembering.
Back in September 2021, git-lfs 3.0.0
released support for using SSH as the transfer protocol instead of HTTP.
Prior to git-lfs 3.0.0, HTTP was the only supported transfer protocol
which meant using git-lfs at GitLab was not possible for some users.
With this release, we’re very excited to offer the ability to
enable support for SSH over HTTP as the transfer protocol for git-lfs.
Thank you to Kyle Edwards and Joe Snyder for this contribution!
An accessible record of deployment events, like deployment approvals, is essential for compliance management. Until now, GitLab did not provide deployment-related audit events, so compliance managers had to use custom tooling or search for this data in GitLab directly. GitLab now provides three audit events:
deployment_started records who started a deployment job, and when it was started.deployment_approved records who approved a deployment job, and when it was approved.deployment_rejected records who rejected a deployment job, and when it was rejected.The compliance center is the central location for compliance teams to manage their compliance standards adherence reporting, violations reporting, and compliance frameworks for their group.
Previously, all of the associated features of the compliance center were only available for top-level groups. This meant that for subgroups, owners didn’t have access to any of the functionality provided by the compliance center on the top-level group.
To help address these key pain points, we’ve added the ability to assign and unassign compliance frameworks for subgroups. Now, group owners can visualize their compliance posture at the subgroup level in addition to the full top-group-level compliance centre dashboard that was already available.
latest templates for each GitLab analyzerScan execution policies have been expanded to allow you to choose between default and latest GitLab templates when defining the policy rules. While default reflects the current behavior, you may update your policy to latest to use features available only in the latest template of the given security analyzer.
By utilizing the latest template, you may now ensure scans are enforced on merge request pipelines, along with any other rules enabled in the latest template. Previously this was limited to branch pipelines or a specified schedule.
Note: Be sure to review all changes between default and latest templates before modifying the policy to ensure this suits your needs!
Administrators can now run a script that identifies dates when multiple access tokens expire. You can use this script in combination with other scripts on the token troubleshooting page to identify and extend large batches of tokens that might be approaching their expiration date, if token rotation has not yet been implemented.
The OAuth authorization screen now more clearly describes the authorization you are granting. It also includes a “verified by GitLab” section for applications that are provided by GitLab. Previously, the user experience was the same, regardless of whether an application was provided by GitLab or not. This new functionality provides an extra layer of trust.
The administrator setup experience for a new install of GitLab has been streamlined and made more secure. The initial administrator root email address is now randomzied, and administrators are forced to change this email address to an account that they can access. Previously, this step could have been delayed, and an administrator might forget to change the email address.
In GitLab 17.2, we’ve added support for the Users API to the GitLab Data Connector, which is available in the Snowflake Marketplace app. You can now stream user data from self-managed GitLab instances to Snowflake using the Users API.
Google Cloud CLI commands are now natively available when setting up workload identity federation for the Google Cloud IAM integration. Previously, the guided setup used a script downloaded through cURL commands. Also, help text has been added to better describe the setup process. These improvements help group owners set up the Google Cloud IAM integration more quickly.
In GitLab 17.2, wiki page titles are separate from their paths. In previous releases, if a page title changed, the path would also change, which could cause links to the page to break. Now, if a wiki page’s title changes, the path remains unchanged. Even if a wiki page path changes, an automatic redirect is set up to prevent broken links.
GitLab 17.2 adds several enhancements to how wikis display the sidebar. Now, a wiki displays all pages in the sidebar (up to 5000 pages), displays a table of contents (TOC), and provides a search bar to quickly find pages.
Previously, the sidebar lacked a TOC, making it challenging to navigate to sections of a page. The new TOC feature helps to see the page structure clearly, as well as navigate quickly to different sections, greatly improving usability.
The addition of a search bar makes discovering content easier. And because the sidebar now displays all pages, you can seamlessly browse an entire wiki.
The Terraform module registry now displays Readme files! With this highly requested feature, you can transparently document the purpose, configuration, and requirements of each module.
Previously, you had to search other sources for this critical information, which made it difficult to properly evaluate and use modules. Now, with the module documentation readily available, you can quickly understand a module’s capabilities before you use it. This accessibility empowers you to confidently share and reuse Terraform code across your organization.
Issues, tasks, incidents, requirements, objectives, and key results
all trigger payloads under the Issues Events webhook category. Until now, there has been no way to quickly determine the type of object that triggered the webhook within the event payload. This release introduces an object_attributes.type attribute available on payloads within the Issues events, Comments, Confidential issues events, and Emoji events triggers.
GitLab Advanced SAST is now available as a Beta feature for Ultimate customers. Advanced SAST uses cross-file, cross-function analysis to deliver higher-quality results. It now supports Go, Java, and Python.
During the Beta phase, we recommend running Advanced SAST in test projects, not replacing existing SAST analyzers.
To enable Advanced SAST, see the instructions.
Starting in GitLab 17.2, Advanced SAST is included in the SAST.latest CI/CD template.
This is part of our iterative integration of Oxeye technology. In upcoming releases, we plan to move Advanced SAST to General Availability, add support for other languages, and introduce new UI elements to trace how vulnerabilities flow. We welcome any testing feedback in issue 466322.
API Security already has support for “overrides” which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a “per-request script” (APISEC_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for “signing” the request with a secret as a form of authentication.
As a follow up to the Continuous Vulnerability Scanning for Container scanning MVC, during 17.2 we added support for APK and RPM operating system package versions.
This enhancement allows our analyzer to fully support Continuous Vulnerability Scans for Container Scanning advisories by comparing the package versions for APK and RPM operating system purl types.
As a note, RPM versions containing a caret (^) are not supported. Work to support these versions is being tracked in this issue.
During the 17.2 release milestone, we published the following updates.
API Fuzzing already has support for “overrides” which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a “per-request script” (FUZZAPI_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for “signing” the request with a secret as a form of authentication.
During the 17.2 release milestone, we published the following updates:
You can now sort the pipeline schedules list by description, ref, next run, created date, and updated date.
rules:changes:compare_to now supports CI/CD variablesIn GitLab 15.3 we introduced the compare_to keyword for rules:change. This made it possible to define the exact ref to compare against. Beginning in GitLab 17.2, you can now use CI/CD variables with this keyword, making it easier to define and reuse compare_to values in multiple jobs.
We’re releasing GitLab Runner 17.2 today! GitLab Runner is the lightweight, highly scalable 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.
livenessProbe and readinessProbeumask 0000 command for the Kubernetes executorFor a list of all changes, see the GitLab Runner CHANGELOG.
With this release, we’ve implemented a new authorization strategy for workspaces to address the limitations of the legacy strategy while providing group owners and administrators more control and flexibility. With the new authorization strategy, group owners and administrators can control which cluster agents to use for hosting workspaces.
To ensure a smooth transition, users on the legacy authorization strategy are migrated automatically to the new strategy. Existing agents that support workspaces are allowed automatically in the root group where these agents are located. This migration also occurs even if these agents have been allowed in different groups in a root group.
On June 20, 2024, GitLab 17.1 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Shubham Kumar completed 7 issues during 17.1 and has been consistently contributing to GitLab since 2021. He has now reached over 50 merged contributions! Shubham is a GitLab Hero and a former Google Summer of Code contributor.
Shubham was nominated by Christina Lohr, Senior Product Manager at GitLab. “Shubham has helped with a lot of issues over the past weeks and months, specifically with closing gaps in our API offering,” says Christina. “I cannot write release posts fast enough for all the additions that Shubham is pushing through!”
“The open-source community is amazing,” says Shubham. “I am grateful for the opportunity and recognition, and I look forward to continuing my contributions to the GitLab platform.”
Joe Snyder was nominated by Kai Armstrong, Principal Product Manager at GitLab, for building a much requested feature for restricting diffs from being included in emails. This contribution took more than 10 merge requests going back to GitLab 15.3. “This is a massive feature that’s taken many milestones, complicated migrations, and changes to the product to enable it’s support,” says Kai. “Joe worked tirelessly with many maintainers and collaborators over the milestones to get this work done.”
Jocelyn Eillis, Product Manager at GitLab, supported Joe’s nomination
by highlighting additional work to fix a bug where nested variables in build:resource_group are not expanded.
“This bug had 23 upvotes in addition to documented customer demand in the issue itself,” says Jocelyn.
“The quick turnaround on reviewer feedback means we were able to get this into GitLab 17.1!”
This is Joe’s second GitLab MVP after previously being awarded in GitLab 16.6. Joe is a Senior R&D Engineer at Kitware and has been contributing to GitLab since 2021.
GitLab now officially supports model registry in beta as a first-class concept. You can add and edit models directly via the UI, or use the MLflow integration to use GitLab as a model registry backend.
A model registry is a hub that helps data science teams manage machine learning models and their related metadata. It serves as a centralized location for organizations to store, version, document, and discover trained machine learning models. It ensures better collaboration, reproducibility, and governance over the entire model lifecycle.
We think of the model registry as a cornerstone concept that enables teams to collaborate, deploy, monitor, and continuously train models, and are very interested in your feedback. Please feel free to drop us a note in our feedback issue and we’ll get back in touch!
GitLab Duo Code Suggestions in VS Code will now show you if there are multiple suggestions available. Simply hover over the suggestion and use the arrows or keyboard shortcut to cycle through the suggestions.
If a secret, like a key or an API token, is accidentally committed to a Git repository, anyone with repository access can impersonate the user of the secret for malicious purposes. To address this risk, most organizations require exposed secrets to be revoked and replaced, but you can save remediation time and reduce risk by preventing secrets from being pushed in the first place.
Secret push protection checks the content of each commit pushed to GitLab. If any secrets are detected, the push is blocked and displays information about the commit, including:
Need to bypass secret push protection for testing? When you skip secret push detection, GitLab logs an audit event so you can investigate.
Secret push protection is available on GitLab.com and for Dedicated customers as a Beta feature and can be enabled on a per project basis. You can help us improve secret push protection by providing feedback in issue 467408.
In earlier versions of GitLab, some customers needed an autoscaling solution for GitLab Runner on virtual machine instances on public cloud platforms. These customers had to rely on the legacy Docker Machine executor or custom solutions stitched together by using cloud provider technologies.
Today, we’re pleased to announce the general availability of the GitLab Runner Autoscaler. The GitLab Runner Autoscaler is composed of GitLab-developed taskscaler and fleeting technologies and the cloud provider plugin for Google Compute Engine.
Audit events are created and stored in GitLab. Before this release, audit events could only be accessed from in GitLab, with results reviewed using the GitLab UI or set a streaming destination to receive all audit events as structured JSON.
However, customers also wanted the ability to have audit events in third-party destinations (such as SIEM solutions like Snowflake) to make it easier to:
To help customers with these tasks, we have created a GitLab connector application for the Snowflake Marketplace, which uses the Audit events API. To make use of this functionality, customers must deploy and manage the application using the Snowflake Marketplace.
The wiki feature in GitLab 17.1 provides a more unified and efficient workflow:
These enhancements improve ease of use, discoverability, and content management in your wiki’s workflow. We want your wiki experience to be efficient and user-friendly. By making cloning repositories more accessible, relocating key options for better visibility, and allowing for the creation of empty placeholders, we’re refining our platform to better meet your users’ needs.
With the addition of the new Reports Generation Tool for Value Stream Management, we empower decision-makers to be more efficient and effective in the software development life cycle (SDLC) optimization.
You can now schedule DevSecOps comparison metrics reports or the AI Impact analytics report to be delivered automatically, proactively, and with relevant information in GitLab issues. With scheduled reports, managers can focus on analyzing insights and making informed decisions, rather than spending time manually searching for the right dashboard with the required data.
You can access the scheduled reports tool using the CI/CD Catalog.
The GitLab container registry now associates signed container images with their signatures. With this improvement, users can more easily:
This improvement is generally available only on GitLab.com. Self-managed support is in beta and requires users to enable the next-generation container registry, which is also in beta.
Manual jobs can be used to trigger highly critical operations in your CI pipeline, such as deploying to production. With this release, you can now configure a manual job to require confirmation before it runs. Use manual_confirmation with when: manual to display a confirmation dialog in the UI when a job is run manually. Requiring confirmation for manual jobs provides an additional layer of security and control.
Special thanks to Phawin for this community contribution!
Operators of self-managed runner fleets at the group level need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. With the runner fleet dashboard for groups, you directly have runner fleet observability and actionable insights in the GitLab UI. You can now quickly determine the runner health, and gain insights into runner usage metrics as well as CI/CD job queue service capabilities, in your organization’s target service-level objectives.
Customers on GitLab.com can use all of the fleet dashboard metrics available for groups today. Self-managed customers can use most of the fleet dashboard metrics, but must configure the ClickHouse analytics database to use the Runner usage and Wait time to pick a job metrics.
GitLab 17.1 includes packages for supporting Ubuntu Noble 24.04.
markedForDeletionOn for groups and projectsYou can now use the new GraphQL API argument markedForDeletionOn to list the groups or projects that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
You can now create badge links and image URLs using four new placeholders:
%{project_namespace} - referencing the full path of a project namespace%{group_name} - referencing the group name%{gitlab_server} - referencing the group’s or project’s server name%{gitlab_pages_domain} - referencing the group’s or project’s domain nameThank you @TamsilAmani for this community contribution!
%{latest_tag} placeholder for badgesYou can now create badge links and image URLs using a %{latest_tag} placeholder. This placeholder references the latest tag that was published for a repository.
Thank you @TamsilAmani for this community contribution!
marked_for_deletion_on date with the Groups APIYou can now filter responses in the Groups API using the attribute marked_for_deletion_on, which returns groups that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
You can now use the new GraphQL API field User.contributedProjects to list the projects a user has contributed to.
Thank you @yasuk for this community contribution!
Previously, when using the Members API, you could add members to groups and projects only by their user ID. With this release, you can now add members also by their username.
Thank you @imskr for this community contribution!
We have updated the sorting and filtering functionality of the group and project Explore pages. The filtering bar is now wider for better readability.
In the Explore page for projects, you can now use standardized sorting options that include Name, Created date, Updated date, and Stars, and a navigation element to sort in ascending or descending order. The language filter has moved to the filter menu. A new Inactive tab displays archived projects for a more focused search. Additionally, you can use a Role filter to search for projects you are the Owner of.
In the Explore page for groups, we have standardized the sorting options to include Name, Created date, and Updated date, and added a navigation element to sort in ascending or descending order.
We welcome feedback about these changes in issue 438322.
Previously, a group’s or project’s general settings displayed only permitted visibility levels. This view often confused users who tried to understand why the other options were not available, and could lead to information being displayed incorrectly. The new view shows all visibility levels, greying out the options that are not available for selection. In addition, a popover gives further context about why an option is not available. For example, a visibility level could be unavailable because an administrator restricted it, or it would cause a conflict with a project’s or parent group’s visibility setting.
We hope these changes help you resolve the conflicts in selecting your desired visibility option. Thank you @gerardo-navarro for this community contribution!
marked_for_deletion_on date with the Projects APIYou can now filter responses in the Projects API using the attribute marked_for_deletion_on, which returns projects that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
Audit events make a record of important actions that are performed in GitLab. Until now, no audit event was created when a system, group, or project webhook was added by a user.
In this release, we’ve added an audit event for when a user creates a system, group, or project webhook.
Until now cancelling a running direct transfer migration required access to a Rails console.
In this release, we’ve added the ability for Administrators to cancel a migration by using the REST API.
Previously, you could test only project hooks with the REST API. With this release, you can also trigger test hooks for specified groups.
This endpoint has a special rate limit of three requests per minute per group hook. To disable this limit on self-managed GitLab and GitLab Dedicated, an administrator can disable the web_hook_test_api_endpoint_rate_limit feature flag.
Thanks to Phawin for this community contribution!
When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items aren’t imported.
In this release, we’ve added an API endpoint that re-imports a named relation, skipping items that have already been imported. The API requires both:
Until now, inherited memberships were not imported reliably when migrating by direct transfer. This meant that inherited members of projects were imported as direct members.
From this release, GitLab now first migrates group membership before migrating project memberships. This replicates the inherited memberships on the source GitLab instance.
In GitLab 16.11, we introduced the ability to add custom headers when you create or edit a webhook.
With this release, you can now use the GitLab REST API to set custom webhook headers.
Thanks to Niklas for this community contribution!
The gitlab-backup tool now supports backing up external merge request diffs stored on local disk. Note, the gitlab-backup tool does not backup files stored on object storage. Therefore, if external merge diffs are stored on object storage they will need to be backed up manually.
The backup-utility for Cloud Native Hybrid environments already supported backing up external merge request diffs and this functionality remains unchanged.
When you review code in a merge request and comment on a line of code, GitLab includes a few lines of the diff in the email notification to participants. Some organizational policies treat email as a less secure system, or might not control their own infrastructure for email. This can present risks to IP or access control of source code.
New settings are available in groups and projects to enable organizations to remove diff previews from merge request emails. This can help ensure that sensitive information isn’t available outside of GitLab.
A gigantic thank you to Joe Snyder for contributing this!
Administrators can now search users by partial email address in the User overview of the Admin Area. For instance, you can filter users by a specific email domain to find all users from a distinct institution. This feature is limited to administrators to prevent unprivileged users from accessing email addresses of other accounts.
Thanks @zzaakiirr for this community contribution!
Do you need to be notified when a new release is posted? GitLab now provides an RSS feed for releases. You can subscribe to a release feed with the RSS icon on the project release page.
Thanks to Martin Schurz for the contribution!
In GitLab 17.1, you can create custom roles with the following new permissions:
With custom roles, you can reduce the number of users with the Owner role by creating users with equivalent permissions. This helps you define roles that are tailored specifically to the needs of your group, and prevents unnecessary privilege escalation.
Building on the previous iteration, we are introducing a new option within the policy editor allowing users to toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the policy editor view.
For example, a merge request policy configured to fail open allows a merge request to merge if there is not enough evidence to evaluate the criteria. The lack of evidence might be because an analyzer is not enabled for the project, or the analyzer failed to produce results for the policy to evaluate. This approach allows for progressive rollout of policies as teams work to ensure proper scan execution and enforcement.
Both project Owners and Maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. Previously, only project Maintainers received this notification. This helps keep more people informed about upcoming token expiration.
Thank you Jacob Henner for your contribution!
GitLab 17.1 enhances the handling of high-resolution images, enabling them to be downscaled during upload. Previously, images displayed in their original size, resulting in suboptimal display quality. This improvement ensures large images don’t break the visual flow of the pages they are included in.
Previously, moving media in the rich text editor required you to copy and paste each item manually. This often slowed down the inclusion of media in issues, epics, and wikis. In GitLab 17.1, you can now drag and drop media in the rich text editor, significantly enhancing efficiency during editing.
GitLab can be configured to enforce client authentication with SSL certificates. However, the GitLab Pages service was incompatible with that feature, because it couldn’t be configured to use client certificates, and calls to the internal API were rejected.
From GitLab 17.1, you can configure a client certificate for GitLab Pages. This allows you to enable client authentication with the GitLab API, strengthening the security of your GitLab instance.
GitLab 17.1 introduces a significant enhancement to wiki page redirects. When you rename a wiki page, anyone trying to access the old page is automatically redirected to the new page, ensuring all existing links remain functional. This improvement streamlines the workflow for managing page name changes and enhances the overall knowledge management experience.
In GitLab 17.1 we’ve improved the Pages user interface. Improvements include more efficient use of screen space. These UI improvements are focused on improving user experience and efficiency when managing Pages.
Previously, the published timestamp was often incorrect in the container registry user interface. This meant that you couldn’t rely on this important data to find and validate your container images.
In GitLab 17.1, we’ve updated the UI to include accurate last_published_at timestamps. You can find this information by navigating to Deploy > Container Registry and selecting a tag to view more details. The last published date is available at the top of the page.
This improvement is generally available only on GitLab.com. Self-managed support is in beta and available only on instances that have enabled the beta next-generation container registry.
You use the GitLab container registry to view, push, and pull Docker or OCI images alongside your source code as well as pipelines. After a container image has been built, you often need to find and validate that it has been built correctly. For many customers, finding the correct container image using the user interface can be challenging.
You can now sort the container registry tags list by publish date. You can use this feature to quickly find and validate the most recently published container image.
This improvement is generally available only on GitLab.com. Self-managed support is in Beta because it requires the next-generation container registry, which is also in Beta. To learn more, see the container registry metadata database documentation.
You’ll now notice a smoother experience when updating issues on boards! Changes you make in the sidebar will instantly appear on the board itself, no more refreshing required. This reactive boards experience streamlines your workflow, allowing you to quickly make updates while seeing them reflected in real-time.
With this release, you can now set time estimates and record time spent on tasks with a quick action or in the time tracking widget in the task’s sidebar. Time spent on a task can be viewed with the task’s time tracking report.
You can now easily see the overall progress of an epic based on the weight completion of its child items. This new progress rollup in the hierarchy widget makes it easier to understand the full scope of work for an epic and track progress as you go.
GitLab 17.1 adds the following configuration variables for API Security Testing:
APISEC_SUCCESS_STATUS_CODES creates a comma-separated list of HTTP success status codes that define whether an API security testing scanning job has passed.APISEC_TARGET_CHECK_DISABLED disables waiting for the target API to become available before scanning begins.APISEC_TARGET_CHECK_STATUS_CODE specifies the expected status code for the API target availability check. If not provided, any non-500 status code is acceptable to the scanner.These new variables provide greater customization and flexibility to ensure scans run successfully.
DAST API was renamed API Security Testing in 16.10. Variable names now begin with the prefix APISEC. Previously, they began with DAST_API. Variables prefixed with DAST_API will be supported until 18.0 (May 2025). To ensure your configurations work as expected, you should update your variable names as soon as possible.
GitLab Composition Analysis now supports Container Scanning for Registry.
If Container Scanning for Registry has been enabled on a project, and a container image is pushed to the container registry in your project, GitLab checks its tag and scan limit.
If the tag is latest, and the number of scans is under the limit (50 scans/day), then GitLab creates a new pipeline that runs a container_scanning job on the image. The pipeline is associated with the user who pushed the image to the registry.
The scan job generates a CycloneDX SBOM that is uploaded to GitLab. The Continuous Vulnerability Scanning features are activated and scan the packages detected in the SBOM.
Note: a vulnerability scan is only perfomed when a new advisory is published. This occurs when the package metadata is synchronized.
As always, we appreciate feedback on our newly released features. To provide feedback, please comment on this feedback issue.
GitLab 17.1 adds the following configuration variables for Fuzz Testing:
FUZZAPI_SUCCESS_STATUS_CODES creates a comma-separated list of HTTP success status codes that define whether a Fuzz Testing job has passed.FUZZAPI_TARGET_CHECK_SKIP disables waiting for the target API to become available before scanning begins.FUZZAPI_TARGET_CHECK_STATUS_CODE specifies the expected status code for the API target availability check. If not provided, any non-500 status code is acceptable to the scanner.These new variables provide greater customization and flexibility for ensuring scans run.
To better control who can override user-defined variables, we are introducing the ci_pipeline_variables_minimum_role project setting. This new setting provides greater flexibility than the existing restrict_user_defined_variables setting. You can now restrict override permissions to no users, or only users with at least the Developer, Maintainer, or Owner roles.
Today we’re releasing GitLab Runner 17.1! GitLab Runner is the lightweight, highly scalable 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.
The list of all changes is in the GitLab Runner change log.
On May 16, 2024, GitLab 17.0 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination 🙌
Niklas van Schrick now has the hat trick with three MVPs and has become one of GitLab’s most consistent contributors with at least one merge request per milestone since GitLab 14.3.
Niklas was nominated by Magdalena Frankiewicz, Product Manager at GitLab, for contributing a feature to create custom webhook payload templates and then following it up with the ability to specify custom webhook headers. “This solved a highly demanded 7-year-old feature request with 65 upvotes,” says Magdalena. “Users can now fully design custom webhooks!”
Niklas is a member of the GitLab Core Team and helps the wider community and GitLab live up to our mission to enable everyone to contribute.
“During my journey, I interacted with a lot of different reviewers, maintainers, designers, technical writers, product managers, and probably more,” Niklas says. “Everyone was helpful and did their best to help move issues and merge requests forward.”
Gerardo Navarro has been contributing to GitLab for over a year and takes home a second GitLab MVP award.
Gerardo was nominated for creating ongoing contributions towards a feature to show protected packages in the package registry list. This feature is part of a series of contributions related to the protected packages epic that intends to increase security by enabling fine-grained permissions to create, update, and delete packages from the package registry.
Many thanks to Gerardo Navarro and the rest of the team from Siemens for helping co-create GitLab.
“Thank you very much for appreciating our work with such a cool award,” says Gerardo. “I feel honored. I am still learning a lot with every contribution.”
The CI/CD Catalog is now generally available. As part of this release, we’re also making CI/CD components and inputs generally available.
With the CI/CD Catalog, you gain access to a vast array of components created by the community and industry experts. Whether you’re seeking solutions for continuous integration, deployment pipelines, or automation tasks, you’ll find a diverse selection of components tailored to suit your requirements. You can read more about the Catalog and its features in the following blog post.
You’re invited to contribute CI/CD components to the Catalog and help expand this new and growing part of GitLab.com!
AI Impact is a dashboard available in the Value Streams Dashboard that helps organizations understand the impact of GitLab Duo on their productivity. This new month-over-month metric view compares the AI Usage trends with SDLC metrics like lead time, cycle time, DORA, and vulnerabilities. Software leaders can use the AI Impact dashboard to measure how much time is saved in their end-to-end workstream, while staying focused on business outcomes rather than developer activity.
In this first release, the AI usage is measured as the monthly Code Suggestions usage rate, and is calculated as the number of monthly unique Code Suggestions users divided by total monthly unique contributors.
The AI Impact dashboard is available to users on the Ultimate tier for a limited time. Afterwards, a GitLab Duo Enterprise license will be required to use the dashboard.
We are excited to introduce hosted runners on Linux Arm for GitLab.com.
The now available medium and large Arm machine types, equipped with 4 and 8 vCPUs respectively, and fully integrated with GitLab CI/CD, will allow you to build and test your application faster and more cost-efficient than ever before.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
You can now link directly to a deployment in GitLab. Previously, if you were collaborating on a deployment, you had to look up the deployment from the deployment list. Because of the number of deployments listed, finding the correct deployment was difficult and prone to error.
From 17.0, GitLab offers a deployment details view that you can link to directly. In this first version, the deployment details page offers an overview of the deployment job and the possibility to approve, reject, or comment on a deployment in a continuous delivery setting. We are looking into further avenues to enhance the deployment details page, including by linking to it from the related pipeline job. We would love to hear your feedback in issue 450700.
GitLab Duo Chat just got a lot better. It now uses Anthropic Claude 3 Sonnet as the base model, replacing Claude 2.1 for answering most questions.
At GitLab, we apply a test-driven approach when choosing the best model for a set of tasks and authoring well-performing prompts. With recent adjustments to the chat prompts, we have achieved significant improvements in the correctness, comprehensiveness, and readability of chat answers based on Claude 3 Sonnet compared to the previous chat version built on Claude 2.1. Hence, we have now switched to this new model version.
A popular capability of GitLab Duo Chat is answering questions about how to use GitLab. While Chat offers various other capabilities, this particular functionality was previously only available on GitLab.com. With this release, we’re making it accessible to GitLab self-managed deployments as well, aligning with our commitment to delivering a delightful experience across all types of deployments.
Whether you’re a newcomer or an expert, you can ask Chat for help with queries like “How do I change my password in GitLab?” or “How do I connect a Kubernetes cluster to GitLab?”. Chat aims to provide helpful information to solve your problems more efficiently.
We enhanced the Value Streams Dashboard with an Overview panel. This new visualization addresses the need for executive-level insights into software delivery performance, and gives a clear picture of GitLab usage in the context of software development life cycle (SDLC).
The Overview panel displays metrics for the group level, such as number of (sub)groups, projects, users, issues, merge requests, and pipelines.
Introduced in GitLab 15.9, the CI/CD job token allowlist prevents unauthorized access from other projects to your project. Previously, you could allow access at the project level from other specific projects only, with a maximum limit of 200 total projects.
In GitLab 17.0, you can now add groups to a project’s CI/CD job token allowlist. The maximum limit of 200 now applies to both projects and groups, meaning a project allowlist can now have up to 200 projects and groups authorized for access. This improvement makes it easier to add large numbers of projects associated with a group.
rules:exists CI/CD keywordThe rules:exists CI/CD keyword has default behaviors that vary based on where the keyword is defined, which can make it harder to use with more complex pipelines. When defined in a job, rules:exists searches for specified files in the project running the pipeline. However, when defined in an include section, rules:exists searches for specified files in the project hosting the configuration file containing the include section. If configuration is split over multiple files and projects, it can be hard to know which exact project will be searched for defined files.
In this release, we have introduced project and ref subkeys to rules:exists, providing you a way to explicitly control the search context for this keyword. These new subkeys help you ensure accurate rule evaluation by precisely specifying the search context, mitigating inconsistencies, and enhancing clarity in your pipeline rule definitions.
You can now view the status of configuration changes made to your GitLab Dedicated instance infrastructure using the Switchboard configuration page.
All users with access to view or edit your tenant in Switchboard will be able to view changes in the Configuration Change log and track their progress as they are applied to your instance.
Currently, the Switchboard configuration page and change log are available for changes like managing access to your instance by adding an IP to the allowlist or configuring your instance’s SAML settings.
We will be extending this functionality to enable self-serve updates for additional configurations in coming quarters.
The GitLab Operator is now available for production use for cloud-native hybrid installations. See the installation documentation before adopting the GitLab Operator.
Support for a fallback to BusyBox images when you specify custom BusyBox values (global.busybox) is removed. Support for BusyBox-based init containers was deprecated in GitLab 16.2 (Helm chart 7.2) in favor of a common GitLab-based init image.
Support for gitlab.kas.privateApi.tls.enabled and gitlab.kas.privateApi.tls.secretName is also removed. You must use global.kas.tls.enabled and global.kas.tls.secretName instead.
The deprecated queue selector and negate options are removed from the Sidekiq chart.
CentOS Linux 7 will reach end of life on June 30, 2024. This makes GitLab 17.6 the last GitLab version in which we can provide packages for CentOS 7.
Currently, most self-managed customers only utilize a single database. In order to ensure that the setup between GitLab.com and self-managed is the same, we ask self-managed customers to migrate and run two databases by default. In 16.0, two database connections became the default for self-managed installations. In 17.0, we release two database mode as a limited Beta, with the goal to make running decomposed generally available by 19.0. Migration to two databases remains optional in 17.0, but needs to be performed before upgrading to 19.0.
The migration requires downtime.
Self-managed customers can use a tool that executes this migration with some downtime.
We introduced a new gitlab-ctl command that allows you to upgrade your single-database GitLab instances to a decomposed setup.
This setup contains commands that will work with our Linux package.
The actual migration (copying the database) is part of a rake task in the GitLab project.
Previously, when a public group or project invited a private group, the private group was listed only in the Groups tab of the Members page, and private members were not visible to members of the public group. To enable better collaboration between members of these groups, we are now also listing all invited group members in the Members tab, including members from private invited groups. The source of membership will be masked from members that do not have access to the private group. However, the source of membership will be visible to users who have at least the Maintainer role in the project or Owner role in the group, so that they can manage members in their project or group. If the current user viewing the Members tab is unauthenticated or not a member of the group or project, they will not see the private group members. We hope this change will make it easier for group and project members to understand at a glance who has access to a group or project.
Previously, members of groups that were invited to a group or project were visible only in the Groups tab of the Members page. This meant users had to check both the Groups and Members tabs to understand who has access to a certain group or project. Now, shared members are listed also in the Members tab, giving a complete overview of all the members that are part of a group or project at a glance.
In this milestone, we added the ability to import Bitbucket Cloud projects by using the REST API.
This can be a better solution for importing a lot of projects than importing by using the UI.
When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items weren’t imported.
In this release, we added an API endpoint that re-imports a named relation, skipping items that have already been imported. The API requires both:
For larger repositories, you can now view issues from multiple Jira projects in GitLab when you set up the Jira issue integration. With this release, you can:
When you view Jira issues in GitLab, you can filter the issues by project.
To create Jira issues for vulnerabilities in GitLab Ultimate, you can specify only one Jira project.
With this release, you can use the REST API to enable viewing Jira issues in GitLab. You can also specify one or more Jira projects to view issues from.
Thanks to Ivan for this community contribution!
Sometimes there is more than one person involved in resolving a support ticket or the requester wants to keep colleagues up-to date on the state of the ticket.
Now you can have a maximum of 10 external participants without a GitLab account on a Service Desk ticket and regular issues.
External participants receive Service Desk notification emails for each public comment on the ticket, and their replies will appear as comments in the GitLab UI.
Simply use the quick actions /add_email
and remove_email
to add or remove external participants with a few keystrokes.
You can also configure GitLab to
add all email addresses from the Cc header
of the initial email to the Service Desk ticket.
You can tailor all Service Desk email templates to your liking, using Markdown, HTML, and dynamic placeholders. An unsubscribe link placeholder is available to make it easy for external participants to opt out of a conversation.
You can migrate GitLab groups and projects between GitLab instances by using direct transfer.
Until now, imported items were not easily identifiable. With this release, we’ve added visual indicators to items imported with direct transfer, where the creator is identified as a specific user:
You can now integrate 1Password secrets management with the GitLab Duo plugin for JetBrains.
Developers can replace their personal access tokens in their JetBrains IDE settings with 1Password secrets references. This simplifies managing secrets, and enables seamless secrets rotation without manual token updates.
Opening Duo Chat directly from your editor in JetBrains is now even easier.
Use the default Alt+D keyboard shortcut (or set your own) to open Duo Chat quickly and type your question. Use the same keyboard shortcut to close the window.
Following the release of group comment templates in GitLab 16.11, we’re bringing these to projects in GitLab 17.0.
Across an organization, it can be helpful to have the same templated response in issues, epics, and merge requests. These responses might include standard questions that need to be answered, responses to common problems, or good structure for merge request review comments. Project-level comment templates give you an additional way to scope the availability of templates, bringing organizations more control and flexibility in sharing these across users.
To create a comment template, go to any comment box on GitLab and select Insert comment template > Manage project comment templates. After you create a comment template, it’s available for all project members. Select the Insert comment template icon while making a comment, and your saved response will be applied.
We’re really excited about this iteration of comment templates and if you have any feedback, please leave it in issue 451520.
Previously, web commits and automated commits made by GitLab could not be signed. Now you can configure your self-managed instance with a signing key, a committer name, and email address to sign web and automated commits.
With the GitLab agent for Kubernetes, you can share a single agent connection with a group. We aim to support a single agent across a large multi-tenant cluster. However, you might have faced a limitation on the number of connection sharing. Until now, an agent could be shared with only 100 projects and groups using CI/CD, and 100 projects and groups using the user_access keyword. In GitLab 17.0, the number of projects and groups you can share with is raised to 500.
If you need to run multiple agents in a cluster, we would like to hear your feedback in issue 454110.
From GitLab 17.0, you can install GitLab in FIPS mode with the agent for Kubernetes components enabled. Now, FIPS-compliant users can benefit from all the Kubernetes integrations with GitLab.
In past releases, merge requests were tracked in a deployment only if the project’s merge method was Merge commit or Merge commit with semi-linear history. From GitLab 17.0, merge requests are tracked in deployments, including in projects with the merge method Fast-forward merge.
As an instance administrator, when you use multiple browsers or different computers, it is difficult to know which sessions are in Admin Mode and which aren’t. Now, administrators can go to User Settings > Active Sessions to identify which sessions use Admin Mode.
Thank you Roger Meier for your contribution!
You can now use the API to upload a custom avatar for any user type, including bot users. This can be especially helpful for visually distinguishing bot users, such as group and project access tokens or service accounts, from human users in the UI. Thank you Phawin for your contribution!
Previously, you could not edit an existing custom role and its permissions. Now, you can edit a custom role and its permissions without having to re-create the role to make a change.
There are new permissions available you can use to create custom roles:
With the release of these custom permissions, you can reduce the number of Owners needed in a group by creating a custom role with these Owner-equivalent permissions. Custom roles allow you to define granular roles that give a user only the permissions they need to do their jobs, and reduce unnecessary privilege escalation.
Before this release, on self-managed GitLab, custom roles had to be created at the group level. This meant administrators could not centrally manage custom roles for the instance, which resulted in duplicate roles across the instance. Now custom roles are managed at the self-managed instance level. Only administrators can create custom roles, but both administrators and group Owners can assign these custom roles.
For more information on migrating existing custom roles, API endpoints, and workflows, see epic 11851.
This update does not impact custom role workflows on GitLab.com.
A series of improvements have been made to the user experience for custom roles, specifically:
Previously, setting up default branch protection options did not allow for the same level of configuration that the settings for protected branches did.
In this release, we have updated the default branch protection settings to provide the same experience that you have with protected branches. This allows more flexibility in protecting your default branch and simplifies the process to match what already exists in the protected branch settings.
The security policy bot posts a comment on merge requests when they violate a policy to help users understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them. These comments are now optional and can be enabled or disabled within each policy. This gives organizations the flexibility and control to determine how they want to communicate about these policies to their users.
The old implementation of the Vulnerability Report filters wasn’t scalable. We were limited by horizontal space on the page. You can now use the filtered search component to filter the Vulnerability Report by any combination of status, severity, tool, or activity. This change allows us to add new filters, like this proposed filter by identifier.
Compliance operates on a sliding scale for many organizations as they strike a balance between meeting requirements and ensuring developer velocity is not impacted. Merge request approval policies help to operationalize security and compliance in the heart of the DevSecOps workflow - the merge request. We’re introducing a new fail open option for merge request approval policies to offer flexibility to teams who want to ease the transition to policy enforcement as they roll out controls in their organization.
When a merge request approval policy is configured to fail open, MRs will now only be blocked if a policy rule is violated and if that project has the security analyzer properly configured. If an analyzer is not enabled for a project or if the analyzer does not successfully produce results, the policy will no longer consider this a violation for the given rule and analyzer. This approach allows for progressive rollout of policies as teams work to ensure proper scan execution and enforcement.
If you add a secondary email address to your user profile and do not verify it, that email address is now automatically deleted after three days. Previously, these email addresses were in a reserved state and could not be released without manual intervention. This automatic deletion reduces administrator overhead and prevents users from reserving email addresses that they do not have ownership of.
You can use the GitLab package registry to publish and download packages. Sometimes, packages fail to upload due to an error. Previously, there was no way to quickly view packages that failed to upload. This made it challenging to get a holistic view of your organization’s package registry.
Now you can filter the package registry UI for packages that failed to upload. This improvement makes it easier to investigate and resolve any issues you encounter.
We added a new metric to the Value Streams Dashboard: median time to merge. In GitLab, this metric represents the median time between when a merge request was created and when it was merged. This new metric measures DevOps health by identifying the efficiency and productivity of your merge request and code review processes.
By analyzing how this metric evolves in the context of other SDLC metrics, teams can identify low or high productivity months, understand the impact of new DevOps practices on the development speed and delivery process, reduce their overall lead time, and increase the velocity of their software delivery.
GitLab is expanding collaboration by updating our permissions. Now, users with the Reporter role can access Design Management features, enabling product teams to engage more directly in the design process. This change simplifies workflows and accelerates innovation by inviting broader participation from across your organization.
We’ve updated what happens when you delete an epic to better safeguard your project’s structure and data. It’s all about giving you more control and peace of mind while managing your projects.
Now, when you delete a parent epic, instead of deleting all its child records automatically, we preserve them by detaching the parent relationship first. This change provides you with a safer way to manage your epics, ensuring accidental deletions don’t result in losing valuable information.
We expanded the epic sorting options available in the Roadmap view, providing you more flexibility in organizing and prioritizing your projects. You can now sort epics by created date, last updated date, and title. This enhancement lays the groundwork for even more advanced sorting capabilities in the future to help you manage epics more dynamically.
You can now customize Value Streams Dashboard panels using a simplified schema-driven customizable UI framework. In the new format, the fields provide more flexibility of displaying the data and laying out the dashboard panels. With the new framework, administrators can track changes to the dashboard over time. This version history can help you revert to previous versions and compare changes between dashboard versions.
Using this customization, decision-makers can focus on the most relevant information for their business, while teams can better organize and display key DevSecOps metrics.
We reduced the minimum role required to relate issues and tasks from Reporter to Guest, giving you more flexibility to organize work across your GitLab instance while maintaining permissions.
We’ve improved issue boards to offer you clearer insights into your project’s timeline and phases. Now, with milestone and iteration details directly visible on issue cards, you can easily track progress and adjust your team’s workload on the fly. This enhancement is designed to make your planning and execution more efficient, keeping you in the loop and ahead of schedule.
We published the following API Security Testing analyzer updates during the 17.0 release milestone:
As previously announced, we increased the major version number of API Security Testing to version 5 in GitLab 17.0.
Users of Dependency Scanning can now scan Android projects. To configure Android scanning, use the CI/CD Catalog component. Android scanning is also supported for users of the CI/CD template.
Following the deprecation of Python 3.9 as the default Python image, Python 3.11 is now the default image.
As outlined in the deprecation notice, the target for the new default Python version was 3.10. The direct move to Python 3.11 was required to ensure FIPS compliance.
DAST 5 supports both arm64 and amd64 architectures by default. This enables customers to choose the Runner host architecture and optimize cost savings.
GitLab Static Application Security Testing (SAST) now scans the same languages with fewer analyzers, offering a simpler, more customizable scan experience.
In GitLab 17.0, we’ve replaced language-specific analyzers with GitLab-managed rules in the Semgrep-based analyzer for the following languages:
As announced, we’ve updated the SAST CI/CD template to reflect the new scanning coverage and to remove language-specific analyzer jobs that are no longer used.
We resolved a Secret Detection bug that impacted remote rulesets. It’s now possible to override or disable rules via remote rulesets. Remote rulesets offer a scalable way to configure rules in a single place, which can be applied across multiple projects.
Secret Detection now uses an advanced vulnerability tracking algorithm to more accurately identify when the same secret has moved within a file due to refactoring or unrelated changes. A new finding is no longer created if:
Otherwise, the existing workflow (merge request widget, pipeline report, and vulnerability report) will treat the findings the same as before. By ensuring that duplicate vulnerabilities are not reported as secrets shift locations, teams are more easily able to manage leaked secrets.
When using a CI/CD Catalog component, you might want to have it automatically use the latest version. For example, you don’t want to have to manually monitor all the components you use and manually switch to the next version every time there is a minor update or security patch. But using ~latest is also a bit risky because minor version updates could have undesired behavior changes, and major version updates have a higher risk of breaking changes.
With this release, you can opt to use the latest major or minor version of a CI/CD component. For example, specify 2 for the component version, and you’ll get all updates for that major version, like 2.1.1, 2.1.2, 2.2.0, but not 3.0.0. Specify 2.1 and you’ll only get patch updates for that minor version, like 2.1.1, 2.1.2, but not 2.2.0.
We have been hard at work on CI/CD components, including making the process of releasing components to the CI/CD Catalog a consistent experience. As part of that work, we’ve made releasing versions from a CI/CD job with the release keyword and the release-cli image the only method. All improvements to the release process will apply to this method only. To avoid breaking changes introduced by this restriction, make sure you always use the latest version of the image (release-cli:latest) or at least a version greater than v0.17. The Releases option in the UI is now disabled for CI/CD component projects.
after_script commands for canceled jobsThe after_script CI/CD keyword is used to run additional commands after the main script section of a job. This is often used for cleaning up environments or other resources that were used by the job. However, after_script commands did not run if a job was canceled.
As of GitLab 17.0, after_script commands will always run when a job is canceled. To opt out, see the documentation.
We’re also releasing GitLab Runner 17.0 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On April 18, 2024, GitLab 16.11 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Ivan Shtyrliaiev has made half a dozen contributions to GitLab so far in 2024. He was nominated by Hannah Sutor, Principal Product Manager at GitLab, who highlighted his contribution to improve the Users list search and filter experience.
“This is a huge user experience improvement that helps us go from a horizontally scrollable list of tabs to a much more elegant UX with only 2 tabs and a search box,” Hannah said. “Now users are able to filter down via the search box rather than horizontally scroll tabs!”
Ivan was noted for picking up this challenging request, working with the GitLab UX team to refine the proposal, and being super responsive to reviews. Adil Farrukh, Engineering Manager at GitLab, supported the nomination, noting that this feature was not trivial and that Ivan was very responsive to feedback. Eduardo Sanz García, Sr. Frontend Engineer at GitLab, also supported the nomination and commended Ivan’s resilience.
“Really appreciate Eduardo’s review and the GitLab team putting in so much effort to make contributions happen,” Ivan said. “It was very helpful and I realise how much time it takes.”
Ivan is a frontend software engineer at Politico.
Baptiste Lalanne picked up a three-year-old issue with nearly seventy upvotes to contribute a highly requested feature that adds retry:exit codes to the CI/CD configuration.
This contribution empowers our users with enhanced flexibility in managing failed pipeline jobs and jobs with different exit codes.
Baptiste was nominated by Dov Hershkovitch, Product Manager at GitLab. “Baptiste’s diligent work on this project went above and beyond mere implementation,” Dov said. “This accomplishment serves as a prime example of our community’s collaborative strength. Through Baptiste’s efforts, GitLab has not only fulfilled a critical need but also reinforced its commitment to openness and transparency, enriching our open-core mentality.”
“This is heart warming and really appreciated,” Baptiste said. “I’m really looking forward to continuing my contributions in my spare time as I love it so much.”
Over the past year, Baptiste has merged six merge requests to GitLab and is looking to contribute to the GitLab Runner next. Baptiste is a software engineer for DataDog.
A big thanks to our newest MVPs, Ivan and Baptiste, and to the rest of GitLab’s community contributors! 🙌
GitLab Duo Chat is now generally available. As part of this release, we are also making these capabilities generally available:
Users can access GitLab Duo Chat in the GitLab UI, in the Web IDE, in VS Code, or in JetBrains IDEs.
Learn more about this release of GitLab Duo Chat from this blog post.
Chat is currently freely accessible by all Ultimate and Premium users. Instance administrators, group owners, and project owners can choose to restrict Duo features from accessing and processing their data.
The GitLab Duo Chat is part of GitLab Duo Pro. To ease the transition for Chat beta users who have yet to purchase GitLab Duo Pro, Duo Chat will remain available to existing Premium and Ultimate customers (without the add-on) for a short period of time. We will announce when access will be restricted to Duo Pro subscribers at a later date.
Feel free to share your thoughts by clicking the feedback button in the chat or by creating an issue and mentioning GitLab Duo Chat. We’d love to hear from you!
We are happy to announce the availability of GitLab Duo Chat in JetBrains IDEs.
As part of GitLab’s AI offerings, Duo Chat further streamlines the developer experience by directly bringing an interactive chat window into any supported JetBrains IDE and the ability to explain code, write tests, and refactor existing code.
For a complete list of capabilities, see our Duo Chat documentation.
Policy scoping provides granular management and enforcement of policies. Across both merge request approval (scan result) policies and scan execution policies, this new feature enables security and compliance teams to scope policy enforcement to a compliance framework or to a set of included/excluded projects in a group.
While today all policies managed in a security policy project are enforced against all linked groups, subgroups, and projects, policy scoping will allow you to refine that enforcement policy by policy. This allows security and compliance teams to:
It is critical to understand how your users are engaging with your application in order to make data-driven decisions about future innovations and optimizations. Are you seeing an uptick in usage for your top business critical URLs, is there an unusual dip in monthly active users, are you seeing more customers engaging with a mobile Android device? By having the answers to questions like this and making them accessible to your engineering teams from the GitLab platform, your teams can stay in sync with how their development work is affecting user outcomes.
With GitLab’s new Product Analytics feature, you can instrument your applications, collect key usage and adoption data about your users, and then display it inside GitLab. You can visualize data in dashboards, report on it, and filter it in a variety of different ways to find insights about your users. Your team can now quickly identify and respond to unexpected dips or spikes in customer usage that signify an issue, as well as celebrate the success of their recent releases.
To use Product Analytics, you will need a Kubernetes cluster to install this helm chart and instrument your application to send traffic to it. GitLab will then connect to the cluster to retrieve the data for visualization.
GitLab.com group Owners can now disable the creation and use of personal access tokens for any enterprise users in their groups. Due to the powerful privileges that can be associated with personal access tokens, some Owners may want to disable these tokens for security reasons.
This granular control gives options when it comes to balancing security and accessibility on GitLab.com.
We’re thrilled to introduce autocomplete support for links to wiki pages in GitLab 16.11! With this new feature, linking to wiki pages from your epics and issues has never been easier - it’s just a matter of a few keystrokes.
Gone are the days of having to copy and paste wiki page URLs into epic and issue comments. Now, simply navigate to any group or project with wiki pages, access an epic or issue, and use the autocomplete shortcut to seamlessly link to your wiki pages from the epic or issue!
We’ve redesigned the project overview page. Now you can find all of the project information and links in one sidebar rather than multiple areas.
Configuration changes made to your GitLab Dedicated instance by tenant administrators using Switchboard will now generate email notifications when complete.
All users with access to view or edit your tenant in Switchboard will receive a notification for each change made.
Sometimes after you notice a job fails, you might manually cancel the rest of the pipeline to save resources while you work on the issue causing the failure. With GitLab 16.11, you can now configure pipelines to be cancelled automatically when any job fails. With large pipelines that take a long time to run, especially with many long-running jobs that run in parallel, this can be an effective way to reduce resource usage and costs.
You can even configure a pipeline to immediately cancel if a downstream pipeline fails, which cancels the parent pipeline and all other downstream pipelines.
Special thanks to Marco for contributing to the feature!
attempt_auto_pg_upgrade? setting to true, which will attempt to automatically upgrade the version of PostgreSQL to 14.This process is the same as for last time we bumped the minimum-supported PostgreSQL version.Now it’s easier to identify archived projects in project lists. From 16.11, archived projects display an Archived badge in the Archived tab of the group overview. This badge is also part of the project title on the project overview page.
An alert message clarifies that archived projects are read-only. This message is visible on all project pages to ensure that this context is not lost even when working on sub-pages of the archived project.
In addition, when deleting a group, the confirmation modal now lists the number of archived projects to prevent accidental deletions.
Previously, GitLab webhooks did not support custom headers. This meant you could not use them with systems that accept authentication tokens from headers with specific names.
With this release, you can add up to 20 custom headers when you create or edit a webhook. You can use these custom headers for authentication to external services.
With this feature and the custom webhook template introduced in GitLab 16.10, you can now fully design custom webhooks. You can configure your webhooks to:
Like secret tokens and URL variables, custom headers are reset when the target URL changes.
Thanks to Niklas for this community contribution!
Previously, you could test project hooks in the GitLab UI only. With this release, you can now trigger test hooks for specified projects by using the REST API.
Thanks to Phawin for this community contribution!
Previously, you could configure the GitLab for Slack app for one project at a time only. With this release, it’s now possible to configure the integration for groups or instances and make changes to many projects at once.
This improvement brings the GitLab for Slack app closer to feature parity with the deprecated Slack notifications integration.
Until now, the maximum number of import jobs for:
These limits were hard-coded and couldn’t be changed. These limits might have slowed down imports, because they might have been insufficient to allow the import jobs to be processed at the same rate they were enqueued.
In this release, we’ve moved the hard-coded limits to application settings. Although we are not increasing these limits on GitLab.com, administrators of self-managed GitLab instances can now configure the number of import jobs according to their needs.
Product Analytics is now generally available, and this release includes a custom visualization designer. You can use it to explore your application event data, and build dashboards to help you understand your customers’ usage and adoption patterns.
In the visualization designer, you can now ask GitLab Duo to build visualizations for you by entering plain text requests, for example “Show me the count of monthly active users in 2024” or “List the top urls this week.”
GitLab Duo in Product Analytics is available as an Experimental feature.
You can help us mature this feature by providing feedback about your experience with GitLab Duo in the custom visualization designer in this feedback issue.
Across an organization it can be helpful to have the same templated response in issues, epics, or merge requests. These responses might include standard questions that need to be answered, responses to common problems, or maybe structure for merge request review comments.
Group comment templates enable you to create saved responses that you can apply in comment boxes around GitLab to speed up your workflow. This new addition to comment templates allows organizations to create and manage templates centrally, so all of their users benefit from the same templates.
To create a comment template, go to any comment box on GitLab and select Insert comment template > Manage group comment templates. After you create a comment template, it’s available for all group members. Select the Insert comment template icon while making a comment, and your saved response will be applied.
We’re really excited about this next iteration of comment templates and will also be adding project-level comment templates soon too. If you have any feedback, please leave it in issue 45120.
Because the heroku/buildpacks:20 image used by the Auto Build component of Auto DevOps was deprecated upstream, we are moving to the heroku/builder:20 image.
This breaking change arrives outside a GitLab major release to accommodate a breaking change upstream. The upgrade is unlikely to break your pipelines. As a temporary workaround, you can also manually configure the heroku/builder:20 image and skip the builder sunset errors.
Additionally, we’re planning another major upgrade from heroku/builder:20 to heroku/builder:22 in GitLab 17.0.
The Admin Area users page has been improved.
Previously, tabs horizontally spanned across the top of the users list, making it difficult to navigate to the desired filter.
Now, filters have been combined into the search box, making it much easier to search and filter users.
Thank you Ivan Shtyrliaiev for your contribution!
Webhook events for project and group access tokens are now available.
Previously, email was the only way to get notifications about expiring tokens. A webhook event, if triggered, will be triggered seven days before an access token expires.
As the compliance center becomes the battle station for compliance managers, you can now manage compliance frameworks, and also gain insight into controls that have been created through security policies and linked to a compliance framework.
Enforce security scanners to run in projects that are in-scope for your compliance, enforce two-person approval, or enable vulnerability management workflows through these extensive controls and then roll them up to a compliance framework, ensuring relevant projects within the framework are properly enforced by the control.
You can now use the Applications API to renew application secrets. Previously, you had to use the UI to do this. Now you can use the API to rotate secrets programatically.
Thank you Phawin for your contribution!
The security policy bot gives users context to understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them. We have now extended support in the bot comment to supply additional insight into why an MR may be blocked by a policy, with more granular feedback on how to resolve. Details provided by the comment include:
With these extra details, you can now more quickly understand the state of your MR and self-serve to troubleshoot any issues.
Workload identity federation allows you to securely connect workloads between GitLab and Google Cloud without the use of service account keys. This improves security, because keys can potentially be long-lived credentials that expose a vector for attack. Keys also come with management overhead for creating, securing, and rotating.
Workload identity federation allows you to map IAM roles between GitLab and Google Cloud.
This feature is in Beta and is currently available only on GitLab.com.
In GitLab 16.9 and earlier, it was possible for a project to both inherit security policies from a parent group or subgroup and link to the same security policies project. The result was that policies were duplicated in the policies list.
This issue has been resolved and it is no longer possible to link to a security policies project from which policies are already inherited.
Usernames can only include non-accented letters, digits, underscores (_), hyphens (-), and periods (.).
Usernames must not start with a hyphen (-), or end in a period (.), .git, or .atom.
Username validation now more accurately states this criteria. This improved validation means that you are clearer on your options when choosing your username.
Thank you Justin Zeng for your contribution!
In previous releases, for projects with a GitLab Pages site, it was difficult to find the site URL.
From GitLab 16.11, the right sidebar has a shortcut link to the site, so you can find the URL without needing to check the docs.
You use the GitLab container registry to view, push, and pull Docker and OCI images alongside your source code and pipelines. For many GitLab customers, this works great for container images during the test and build phases. But, it’s common for organizations to publish their production images to a cloud provider, like Google.
Previously, to push images from GitLab to Google Artifact Registry, you had to create and maintain custom scripts to connect and deploy to Artifact Registry. This was inefficient and error prone. In addition, there was no way easy way to get a holistic view of all of your container images.
Now, you can leverage the new Google Artifact Management feature to easily connect your GitLab project to an Artifact Registry repository. Then you can use GitLab CI/CD pipelines to publish images to the Artifact Registry. You can also view images that have published to the Artifact Registry in GitLab by going to Deploy > Google Artifact Registry. To view details about an image, simply select an image.
This feature is in Beta and is currently available only on GitLab.com.
To further improve the ability to use portfolio management features across the organization, you can now distinguish epics using colors on roadmaps and epic boards.
Quickly distinguish between group ownership, stage in a lifecycle, development towards maturity, or a number of other categorizations with this lightweight but versatile feature.
We introduced a more robust method for calculating durations between label events. This change accommodates scenarios where events occur multiple times, such as label changes in merge requests back and forth between development to review states. Previously, the duration was calculated as the total time elapsed between the first and last label event.
Now, the duration is calculated as cumulative time, meaning it now correctly represents only the time when an issue or merge request had a given label.
Users can access dependency graph information in CycloneDX SBOMs generated as a part of their dependency scanning report. Dependency graph information is available for the following package managers:
Dependency Scanning supports Yarn v4. This enhancement allows our analyzer to parse Yarn v4 lockfiles.
During the 16.11 release milestone we completed the following DAST improvements:
Previously, creating GitLab Runners in Google Compute Engine required multiple context switches from GitLab and Google Cloud.
Now, you can easily provision GitLab Runners in Google Compute Engine with a terraform template from the GitLab Runner Infrastructure Toolkit and GitLab to deploy a GitLab runner and provision the Google Cloud infrastructure - without having to switch between multiple systems.
Previously, you could use retry:when in addition to retry:max to configure how many times a job is retried
when specific failures occur, like when a script fails.
With this release, you can now use retry:exit_codes
to configure automatic retries of failed jobs based on specific script exit codes.
You can use retry:exit_codes with retry:when and retry:max to fine-tune your pipeline’s behavior
according to your specific needs and improve your pipeline execution.
Thanks to Baptiste Lalanne for this community contribution!
We’re also releasing GitLab Runner 16.11 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
The GitLab integration with HashiCorp Vault has been expanded to support more types of secrets. You can now select a generic type of secrets engine, introduced in GitLab Runner 16.11. This generic engine supports HashiCorp Vault Artifactory Secrets Plugin and AWS secrets engine. Use this option to safely retrieve the secrets you need and use them in GitLab CI/CD pipelines!
Thanks so much to Ivo Ivanov for this great contribution!
By default, all generated artifacts from CI/CD jobs in a public pipeline are available for download by all users with access to the pipeline. However, there are cases where artifacts should never be downloaded, or only be accessible for download by team members with a higher access level.
So in this release, we’ve added the artifacts:access keyword. Now, users can control whether artifacts can be downloaded by all users with access to the pipeline, only users with the Developer role or higher, or no user at all.
The pipeline graph offers a comprehensive overview of your pipelines, showing job statuses, runtime updates, multi-project pipelines, and parent-child pipelines.
Today, we’re excited to announce the release of the redesigned pipeline graph with enhanced aesthetics, grouped jobs visualization, improved mobile expirence and expanded downstream pipeline visibility within your existing view.
We’d greatly appreciate it if you could try it out and share your feedback through this dedicated issue.
On March 21, 2024, GitLab 16.10 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Lennard Sprong previously won the GitLab MVP award in 15.4 and was also nominated in 16.9. He continues to provide contributions to GitLab Workflow for VS Code, merging 8 contributions in the past two months. Some of his past contributions include the ability to watch the trace of running CI jobs, view downstream pipelines, and compare images in merge requests. Lennard is also actively involved in issues inside the GitLab-vscode-extension project.
Erran Carey, Staff Fullstack Engineer at GitLab, nominated Lennard and noted that “Lennard resolved an issue viewing pipelines affecting GitLab Community Edition users. He pointed impacted users to the existing workaround before creating a merge request to address the issue.”
Tomas Vik, Staff Fullstack Engineer at GitLab, additionally supported Lennard and highlighted a contribution to add support for image diff that allows people to view image changes during merge request review.
Marco Zille also wins his second GitLab MVP award, previously winning in 15.3. Marco was recognized not only for code contributions this release, but also for ongoing efforts supporting GitLab’s wider community of contributors, running community pairing sessions, collaborating with GitLab team members, and reviewing merge requests.
Marco added the ability to cancel a pipeline immediately after one job fails. The feature is enabled and available on GitLab.com but still behind a feature flag for self-hosted instances. It will be made available for everyone in 16.11.
Allison Browne, Senior Backend Engineer at GitLab, nominated Marco for picking up this long standing and highly requested feature request in pipeline execution. Fabio Pitino, Principal Engineer at GitLab, added that “Marco not only implemented the fix but also was instrumental to the design of the feature, bringing use cases and discussing them with customers interested in the feature.”
Peter Leitzen additionally supported Marco’s nomination by highlighting how Marco helped to review and then finish a fix for loading the stack trace from Sentry.
We are so grateful for the continued support from Lennard and Marco to improve GitLab and support our open source community! 🙌
To enforce consistent behavior across published components, in GitLab 16.10 we will enforce Semantic versioning for components that are published to the CI/CD catalog. When publishing a component, the tag must follow the 3-digit semantic versioning standard (for example 1.0.0).
When using a component with the include: component syntax, you should use the published semantic version. Using ~latest continues to be supported, but it will always return the latest published version, so you must use it with caution as it could include breaking changes. Shorthand syntax is not supported, but it will be in an upcoming milestone.
Generative AI is revolutionizing work processes, and you can now facilitate the adoption of these technologies without compromising privacy, compliance, or intellectual property (IP) protections.
You can now disable GitLab Duo AI features for a project, a group, or an instance by using the API. You can then enable GitLab Duo for specific projects or groups when you’re ready. These changes are part of a suite of expected work to make AI features more granular to control.
This version of GitLab introduces all-new templates to the Wiki. Now, you can create templates to streamline creating new pages or modifying existing ones. Templates are wiki pages that are stored in the templates directory in the wiki repository.
With this enhancement, you can make your wiki page layouts more consistent, create or restructure pages faster, and ensure that information is presented clearly and coherently in your knowledge base.
The Contribution Analytics report is now more performant and backed by an advanced analytics database using ClickHouse on GitLab.com. This upgrade set the foundation for new extensive analytics and reporting features, allowing us to deliver high-performance analytics aggregations, filtering, and slicing across multiple dimensions. Support for self-managed customers to be able to add to this capability is proposed in issue 441626.
Although ClickHouse enhances GitLab’s analytics capabilities, it’s not meant to replace PostgreSQL or Redis, and the existing capabilities remain unchanged.
GitLab Pages and Advanced Search have been enabled for all GitLab Dedicated instances. These features are included in your GitLab Dedicated subscription.
Advanced Search enables faster, more efficient search across your entire GitLab Dedicated instance. All capabilities of Advanced Search can be used with GitLab Dedicated instances.
With GitLab Pages, you can publish static websites directly from a repository in GitLab Dedicated. Some capabilities of Pages are not yet available for GitLab Dedicated instances.
You can now offload CI runner traffic to Geo secondary sites. Locate runner fleets where they are more convenient and economical to operate and manage, while reducing cross-region traffic. Distribute the load across multiple secondary Geo sites. Reduce load on the primary site, reserving resources for serving developer traffic. After this setup, the developer experience is transparent and seamless. Developer workflows for the setup and configuration of jobs remain unchanged.
In GitLab 16.10, we’ve removed support for installing GitLab on Kubernetes 1.24 and older. Kubernetes maintenance support of Kubernetes 1.24 ended in July 2023.
GitLab 16.10 includes support for installing GitLab on Kubernetes 1.27. For more information, see our new Kubernetes version support policy. Our goal is to support newer versions of Kubernetes closer to their official release.
GitLab 16.10 introduces a new major version of Patroni, version 3.0.1. This version upgrade will require downtime. For more information and instructions, see the 16.10 section of our GitLab 16 changes page.
GitLab 16.10 also includes a new version of Alertmanager, namely version 0.27. Most notably, this version includes the removal of API v1. For more information on this release, see the Alertmanager changelog.
GitLab 16.10 also includes Mattermost 9.5. Mattermost 9.5 includes various security updates and the deprecation of support for MySQL 5.7. Users on this version of MySQL must update.
With the GraphQL API you can now filter group members by Enterprise users.
Previously, when a user who followed you was blocked, they still appeared in the followers list of your User Profile. From GitLab 16.10, blocked users are hidden from the followers list. If the user is unblocked, they will reappear in the followers list.
Thank you @SethFalco for this community contribution!
You can now filter groups by visibility in the Groups API. You can use filtering to focus on groups with a specific visibility level, making it easier to audit GitLab implementations.
Thank you @imskr for this community contribution!
Now it’s easier to identify deleted projects in project lists. From GitLab 16.10, deleted projects display a Pending deletion badge next to the project title on the project overview page. An alert message clarifies that deleted projects are read-only. This message is visible on all project pages to ensure that this context is not lost even when working on sub-pages of the deleted project.
Previously, notifications sent from GitLab to a space in Google Chat could not be created as replies to specified threads. With this release, threaded notifications are enabled by default in Google Chat for the same GitLab object (for example, an issue or merge request).
Thanks to Robbie Demuth for this community contribution!
Previously, GitLab webhooks could send only specific JSON payloads, which meant the receiving endpoints had to understand the webhook format. To use those webhooks, you had to either use an app to specifically support GitLab or write your own endpoint.
With this release, you can set a custom payload template in the webhook configuration. The request body is rendered from the template with the data for the current event.
Thanks to Niklas for this community contribution!
Now you can create Service Desk tickets from the UI and the API using the /convert_to_ticket user@example.com quick action on a regular issue.
Create a regular issue and add a comment with the /convert_to_ticket user@example.com quick action. The provided email address becomes the external author of the ticket. GitLab doesn’t send the default thank you email. You can add a public comment on the ticket to let the external participant know that the ticket has been created.
Adding a Service Desk ticket using the API follows the same concept: Create an issue using the Issues API and use the issue_iid to add a note with the quick action using the Notes API.
Merge requests can contain changes from users and automated processes or compilers. Files like package-lock.json, Gopkg.lock, and minified js and css files increase the number of files shown in a merge request review, and distract reviewers from the human-generated changes. Merge requests now display these files collapsed by default, to help:
For examples of the file types that are collapsed by default, see the documentation. To collapse more files and file types in the merge request, specify them as gitlab-generated in your project’s .gitattributes file.
You can leave feedback on this change in issue 438727.
The merge widget explains clearly if your merge request is not mergeable, and why. Previously, only one merge blocker was displayed at a time. This increased review cycles and forced you to resolve problems individually, without knowing if more blockers remained.
When you view a merge request, the merge widget now gives you a comprehensive view of problems, both remaining and resolved. Now you can understand at a glance if multiple blockers exist, fix them all in a single iteration, and increase your confidence that no hidden blockers have been missed.
GitLab 16.10 adds a dedicated refresh feature to the dashboard for Kubernetes. Now you can manually fetch Kubernetes resource data, and ensure you have access to the most recent information about your clusters.
The environment details page is improved in GitLab 16.10. When you select an environment from the environment list, you can review up-to-date information about your deployments and connected Kubernetes clusters, all in one convenient layout.
When authenticating with GitLab, it is possible to hit the authentication attempt rate limit, such as when using a script. Previously, if you hit the authentication rate limit, a 403 Forbidden message was returned, which did not explain why you are getting this error. We now return a more descriptive error message which tells you that you’ve hit the authentication rate limit.
scope attributeAudit events now include a scope attribute that indicates if the event is associated with an entire instance, a group, a project, or a user.
This new attribute helps users determine where an event originated in audit event payloads. It also allows our audit event type documentation to list all available scopes for an audit event type.
You can use this new attribute to parse through external streaming destinations or to better understand context around events.
You can now customize a service account’s username and display name. Previously, these were auto-generated by GitLab. With a custom name, it is easier to understand the purpose of the service account, and distinguish it from other accounts in the user list.
GitLab now records an audit event when a user is assigned a different role, regardless of whether that role is a default role or a custom role. This event is important to identify if user permissions have been added or changed in case of privilege escalation.
To create custom roles, you can now choose two new permissions:
With the release of these custom permissions, you can reduce the number of Owners needed in a group by creating a custom role with these Owner-equivalent permissions. Custom roles let you define granular roles that give a user only the permissions they need to do their job, and reduce unnecessary privilege escalation.
As we’ve expanded capabilities of the policy type to support overriding project settings and enforce approval requirements, we’ve updated the policy name to the more apt “merge request approval policy”.
Merge request approval policies do not replace or conflict with existing merge request approval rules. Instead they provide Ultimate tier customers the ability to create global enforcement across projects through policies managed by central security and compliance teams - an increasingly challenging task for large-scale organizations.
You can now configure webhooks to support mutual TLS. This configuration establishes the authenticity of the webhook source and enhances security. You configure the client certificate in PEM format, which is presented to the server during the TLS handshake. You can also protect the certificate with a PEM passphrase.
The GitLab sign-in page has been refreshed with improvements that fix spacing issues, broken elements, and alignment. There is also additional support for dark mode, and a button to manage cookie preferences. The combination of these improvements gives a fresh look and improved functionality on the sign-in page.
Smart card authentication against an LDAP server now supports Entra ID (formerly known as Azure Active Directory). This makes it easy to sync user identity data from Entra ID, and authenticate against LDAP with smart cards.
This enhancement aligns the logic of the merge request approval policy evaluation with the security MR widget, ensuring that findings that violate a merge request approval policy align with the results displayed in the widget. By aligning the logic, security, compliance, and development teams can more consistently identify which findings violate a policy and require approval.
Rather than comparing to the target branch’s latest completed HEAD pipeline, scan result policies now compare to a common ancestor’s latest completed pipeline, the “merge base”.
Previously, GitLab focused on supporting simple redirect rules. In GitLab 14.3, we introduced support for splat and placeholder redirects.
From GitLab 16.10, GitLab Pages supports domain-level redirects. You can combine domain-level redirects with splat rules to dynamically rewrite the URL path. This improvement helps prevent confusion and ensure that you can still find your information after a domain change, even if you use an old domain.
Previously, the container registry relied on the Docker/OCI listing image tags registry API to display tags in GitLab. This API had significant performance and discoverability limitations.
This API performed slowly because the number of network requests against the registry scaled with the number of tags in the tags list. In addition, because the API didn’t track publish time, the published timestamp was often incorrect. There were also limitations when displaying images based on Docker manifest lists or OCI indexes, such as for multi-architecture images.
To address these limitations, we introduced a new registry list repository tags API. In GitLab 16.10, we’ve completed the migration to the new API. Now, whether you use the UI or the REST API, you can expect improved performance, accurate publication timestamps, and robust support for multi-architecture images.
This improvement is available only on GitLab.com. Self-managed support is blocked until the next-generation container registry is generally available. To learn more, see issue 423459.
To enable software leaders to gain insights into the relationship between team velocity, software stability, security exposures, and team productivity, we introduced a new Contributor count metric in the Value Streams Dashboard. The contributor count represents the number of monthly unique users with contributions in the group. This metric is designed to track adoption trends over time, and is based on contributions calendar events.
The Contributor count metric is available only on GitLab.com, and requires the contribution analytics report to be configured to run through ClickHouse. Issue 441626 tracks efforts to make this feature available to self-managed customers as well.
Value stream analytics now applies the same filters when drilling down from the Lead time tile to the Issue Analytics report. The filter inheritance helps you dive deeper and seamlessly into data as you switch between analytics views.
The /iteration quick action now accepts a cadence reference with --current or --next arguments. If your group has a single iteration cadence, you can quickly assign an issue to the current or next iteration by using /iteration --current|next. If your group contains many iteration cadences, you can specify the desired cadence in the quick action by referencing the cadence name or ID. For example, /iteration [cadence:"<cadence name>"|<cadence ID>] --next|current.
Continuous Vulnerability Scanning for Container Scanning is now available by default. The default availability removes the need to opt into this functionality through a feature flag. To learn more about the benefits of Continuous Vulnerability Scanning, see the documentation link.
We have updated the mechanism we use to generate the list of dependencies for projects using sbt. This change is only applicable to projects using sbt version 1.7.2 and later. To fully leverage Dependency Scanning for sbt projects, you should upgrade to sbt version 1.7.2 and later.
During the 16.10 release milestone, proxy-based DAST was:
We also completed the following browser-based DAST crawler performance improvements:
We’re also releasing GitLab Runner 16.10 today! GitLab Runner is the lightweight, highly-scalable 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.
Bug fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
On February 15, 2024, GitLab 16.9 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Ravi is actively working with GitLab’s Vulnerability Research group to address high false-positive results in GitLab SAST.
Ravi was nominated by Rohan Shah, Customer Success Manager at GitLab, who noted Ravi’s significant improvements to the detection rules used in GitLab SAST. Dinesh Bolkensteyn, Senior Vulnerability Researcher at GitLab, added “Ravi’s feedback is spot on, directly actionable and enabled us to improve many of our SAST rules.”
Ravi Dharmawan a.k.a ravidhr works at GoTo Group as an Information Security Architect. He works mostly on handling secure design review, source code review, and penetration testing. Ravi is OSCP + eWPTXv2 certified.
Ian is the first GitLab MVP recognized for work supporting users on the GitLab Forum.Michael Friedrich, Senior Developer Advocate at GitLab, and Fatima Sarah Khalid, Developer Advocate at GitLab both nominated Ian for continued efforts in helping make our forum a better place for the community by answering questions for users who are setting up and using GitLab.
Ian works at UpWare Sp. z o.o. as a System and Security Consultant, working mostly on Red Hat OpenShift and anything Linux-related. He is Red Hat Certified RHCSA + RHCE and has been managing, maintaining and supporting his own self-hosted GitLab installation since 2017. Ian has been regularly active on the GitLab forums for 3+ years with 2,600+ helpful responses, 480 helpful community moderation flags, and 240 solutions.
Thank you Ravi and Ian! 🙌
In 16.8, we made GitLab Duo Chat available for self-managed instances. In 16.9, we are making Chat available to Premium customers while it is still in Beta.
GitLab Duo Chat can:
GitLab Duo Chat is available as a Beta feature. It is also integrated into our Web IDE and GitLab Workflow extension for VS Code as Experimental features. In these IDEs, you can also use predefined chat commands that help you do standard tasks more quickly like writing tests.
You can help us mature these features by providing feedback about your experiences with GitLab Duo Chat, either within the product or through our feedback issue.
The last part of reviewing a merge request is communicating the outcome. While approving was unambiguous, leaving comments was not. They required the author to read your comments, then determine if the comments were purely informational, or described needed changes. Now, when you complete your review, you can select from three options:
The sidebar now shows the outcome of your review next to your name. Currently, ending your review with Request changes doesn’t block the merge request from being merged, but it provides extra context to other participants in the merge request.
You can leave feedback about the Request changes feature in our feedback issue.
In GitLab 16.9, we have released a series of improvements to the CI/CD variables user experience. We have improved the variables creation flow through changes including:
Other improvements include a new, optional description field for group and project variables to assist with the management of variables. We have also made it easier to add or edit multiple variables, lowering the friction in the software development workflow and enabling developers to perform their job more efficiently.
Your feedback for these changes is always valued and appreciated.
Currently, to use the auto-cancel redundant pipeline feature, you must set jobs that can be cancelled as interruptible: true to determine whether or not a pipeline can be cancelled. But this only applies to jobs that are actively running when GitLab tries to cancel the pipeline. Any jobs that have not yet started (are in “pending” status) are also considered safe to cancel, regardless of their interruptible configuration.
This lack of flexibility hinders users who want more control over which exact jobs can be cancelled by the auto-cancel pipeline feature. To address this limitation, we are pleased to announce the introduction of the auto_cancel:on_new_commit keywords with more granular control over job cancellation. If the legacy behavior did not work for you, you now have the option to configure the pipeline to only cancel jobs that are explicitly set with interruptible: true, even if they haven’t started yet. You can also set jobs to never be automatically cancelled.
As a GitLab administrator, you can now set the maximum number of Elasticsearch code-indexing background jobs that can run concurrently. Previously, you could only limit the number of concurrent jobs by creating dedicated Sidekiq processes.
Administrators can now add text guidelines that are visible to users with permissions to manage members on the Members page of a group or project. Administrators can access these guidelines in the Appearance section of the Admin Area settings.
Guidelines are helpful for teams that use external tooling to manage members of groups or projects. For instance, the guideline can link to predefined groups that users should use instead of managing membership for individual members.
Thank you @bufferoverflow for this community contribution!
Completed migrations of GitLab groups and projects by direct transfer have displayed badges (Complete, Partially completed, and Failed) to inform users about the general end result of the migration. Users could also access a list of items that were not imported, by clicking on the See failures link.
However, for a partially-imported project, there was no quick way to understand how many items of each type were successfully imported and how many were not.
In this release, we added import results statistics for groups and projects. To access the statistics, select the Details link on the direct transfer history page.
With this release, you can enable Jira issues for all projects in a GitLab group. Previously, you could only enable Jira issues for each GitLab project individually.
With this release, we’ve added REST API support for the GitLab for Slack app.
You cannot create a GitLab for Slack app from the API. Instead, you must install the app from the GitLab UI. You can then retrieve the integration settings and update or disable the app for a project.
Self-managed users can now seamlessly access Service Ping data through a REST API connection, facilitating direct integration with downstream systems. This represents a significant improvement over the previous method of file download. The new approach offers self-managed users a more efficient and real-time means of conducting customized analysis and deriving specific insights from their GitLab usage data.
Previously, Git access control options on GitLab.com relied on credentials set up in the user account. Now you can set up a process to make Git access possible using only SSH certificates. You can also use these certificates to sign commits.
In GitLab 16.8, we introduced settings for the GitLab agent for Kubernetes to limit the CPU and memory usage per workspace.
Now in 16.9, you can also limit the number of workspaces per user. With this new setting, you have even more control over your cloud resources and can prevent individual developers from inflating cloud spend.
The Environment auto_stop_in functionality was updated to run the job from the last finished pipeline, instead of the last successful pipeline. This avoids edge cases where the auto stop job can not run because of not having any successful pipelines.
This behaviour might be considered a breaking change in some situations. The new behaviour is currently behind a feature flag, and will become the default in 17.0, and at the same time, we are going to deprecate the old behaviour to be removed from GitLab in 18.0. We recommend everyone to start transitioning or to configure the feature flag immediately to minimize the risks of the breaking change at the first 17.x upgrade.
This release adds full support for Kubernetes version 1.29, released in December 2023. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
Group Owners that have enterprise users can now use both the user management UI and the group and project members API to see those users’ email addresses. Previously, only provisioned users’ email addresses were returned.
Previously, if a group had LDAP sync enabled, administrators were not able to invite or remove any users from that group. Now, administrators can use the group and project members API to invite service account users to or remove those users from a group with LDAP sync. Administrators still cannot invite human users to or remove those users from a group with LDAP sync. This ensures that LDAP group sync is the single source of truth for human user account membership, while allowing the flexibility to use service accounts to add automations to LDAP-synced groups.
GitLab now records an audit event when a custom role is updated or deleted. This event is important to identify if permissions have been added or changed in case of privilege escalation.
If you belong to a group that requires SAML SSO authentication, but you do not have a valid session for that group, a banner is displayed that prompts you to refresh your session. Previously, issues and merge requests were not displayed when a session had expired, but this was not clear to the user. Now, it is clear to users when they must reauthenticate to see all of their work items.
The standards adherence report, within the compliance center, is the destination for compliance teams to monitor their compliance posture.
In GitLab 16.5, we introduced the report with the GitLab Standard - a set of common compliance requirements all compliance teams should monitor. The standard helps you understand which projects meet these requirements, which ones fall short, and how to bring them into compliance. Over time, we’ll be introducing more standards into the reporting.
In this milestone, we’ve made some improvements which will make reporting more robust and actionable. These include:
In GitLab 16.2, we released the rich text editor as an alternative to the plain text editor. The rich text editor provides a “what you see is what you get” editing interface, and an extensible foundation for additional development. Until this release, however, the rich text editor was available only in issues, epics, and merge requests.
With GitLab 16.9, the rich text editor is now available in:
With improved access to the rich text editor, you can collaborate more efficiently and without previous Markdown experience.
You can use the GitLab package registry to publish and download Terraform modules. By default, you cannot publish the same module name and version more than once per project.
However, you might want to allow duplicate uploads, especially for releases. In this release, GitLab expands the group setting for the package registry so you can allow or deny duplicate modules.
When using the GitLab Terraform registry, it is important to have a cross-project view of all your modules. Until recently, the user interface has been available only at the project level. If your group had a complex structure, you might have had difficulty finding and validating your modules.
From GitLab 16.9, you can view all of your group and subgroup modules in GitLab. The increased visibility provides a better understanding of your registry, and decreases the likelihood of name collisions.
You can now visualize your work in progress limits in a board list. When a limit has been exceeded, an indicator line will appear in the list to help you understand which items are over the limit and manage the list accordingly.
To improve the tracking of development workflows in GitLab, the Value Stream Analytics has been extended with a new stage event: Issue first added to iteration. You can use this event to detect problems caused by a lack of agility from teams planning too far ahead or execution challenges in teams that have issues rolling over from iteration to iteration. For example, you can now add a “Planned” stage that starts when Issue first added to iteration and ends when the Issue first assigned.
We’ve made reporting and stability improvements to Operational Container Scanning (OCS). Notably, the Trivy report size limit has been increased, which provides a more stable experience for users. Expanding the Trivy report size from 10MB to 100MB allows customers who were constrained by the report size limit to leverage OCS in securing container images in their cluster.
With this change to OCS, users who run gitlab-agent in FIPS mode cannot run Operational Container Scanning. For more details on this, see our documentation and please provide feedback in issue #440849.
We resolved the following bugs during the 16.9 release milestone:
We’ve updated more than 40 default GitLab SAST rules to:
The rule changes are included in updated versions of the Semgrep-based GitLab SAST analyzer. This update is automatically applied on GitLab 16.0 or newer unless you’ve pinned SAST analyzers to a specific version. We’re working on more SAST rule improvements in epic 10907.
We’ve improved how security findings are shown in the GitLab Workflow extension for Visual Studio Code (VS Code). You can now see more details of your security findings that weren’t previously shown, including:
We’ve also:
Organizations might want to control which user roles are able to cancel a pipeline. Previously, anyone who could run a pipeline could also cancel a pipeline. Now, a project Maintainer is able to update a setting which restricts pipeline and job cancellation to specific roles, or even prevents cancellation completely!
When managing a GitLab Runner Fleet at scale, you have told us that knowing which projects use the most compute minutes on the runners is critical. For you, this information is essential to help teams optimize CI/CD pipelines and also help you make the right decisions about fleet cost optimization.
Now, the runner compute usage by project metric card, a complement to the previously released CI/CD compute minutes export by CSV feature, is available in the Runner Fleet Dashboard. You can see the top projects that consume instance runner minutes, and the most used instance runners in your GitLab environment.
We’re also releasing GitLab Runner 16.9 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
If you use branch pipelines, you can now quickly view and access the related merge requests from the pipeline details page.
On January 18, 2024, GitLab 16.8 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Ted has made significant contributions removing old and unused code from our helper files and addressing other maintenance tasks. He was nominated by Kerri Miller, Staff Engineer at GitLab, who said, “It’s not always glamorous work, but it’s important work”.
Ted is a freelance software engineer, avid climber, and cat enthusiast based in Orange County.
Martin was nominated by Viktor Nagy, Product Manager at GitLab, who said, “He added many missing tests to the Auto Deploy jobs template and improved the agentk Helm chart documentation”.
Lee Tickett, Engineer at GitLab, added that he “has been joining community pairing sessions on Discord and collaborating closely with team members to contribute a heavily requested search enhancement for merge requests”.
Martin is an IT Architect at Deutsche Telekom MMS GmbH based in Dresden, Germany.
Helio was nominated by Hannah Sutor, Principal Product Manager at GitLab, who said, “he has pushed our entire team forward by proposing the ability to sign in using passkeys. Helio’s MR was closed, but his contribution was deep, thought provoking, and his questions and open discussion will make our Passwordless implementation better”.
Helio is a software engineer with passion for Ruby and OSS.
Thank you Ted, Martin, and Helio! 🙌
Static Analysis now supports displaying the findings in the Merge request changes view. No need to navigate elsewhere – it’s all consolidated in one place. The UI is refined for a more straightforward encounter. For specifics, just open the drawer. Learn more from the linked documentation, demo video and rollout issue.
Secrets stored in Google Cloud Secret Manager can now be easily retrieved and used in CI/CD jobs. Our new integration simplifies the process of interacting with Google Cloud Secret Manager through GitLab CI/CD, helping you streamline your build and deploy processes! This is just one of the many ways GitLab and Google Cloud are better together!
We’re thrilled to share that Workspaces are now generally available and ready to improve your developer efficiency!
By creating secure, on-demand remote development environments, you can reduce the time you spend managing dependencies and onboarding new developers and focus on delivering value faster. With our platform-agnostic approach, you can use your existing cloud infrastructure to host your workspaces and keep your data private and secure.
Since their introduction in GitLab 16.0, workspaces have received improvements to error handling and reconciliation, support for private projects and SSH connections, additional configuration options, and a new administrator interface. These improvements mean that workspaces are now more flexible, more resilient, and more easily managed at scale.
You can now enforce whether GitLab administrators are required to use two-factor authentication (2FA) in their self-managed instance. It is good security practice to use 2FA for all accounts, especially for privileged accounts like administrators. If this setting is enforced, and an administrator does not already use 2FA, they must set up 2FA on their next sign-in.
A typical software project relies on a variety of dependencies, which we call packages. Packages can be internally built and maintained, or sourced from a public repository. Based on our user research, we’ve learned that most projects use a 50/50 mix of public and private packages. Package installation order is very important, as using an incorrect package version can introduce breaking changes and security vulnerabilities into your pipelines.
Now you can add one external Java repository to your GitLab project. After adding it, when you install a package using the dependency proxy, GitLab first checks for the package in the project. If it’s not found, GitLab then attempts to pull the package from the external repository.
When a package is pulled from the external repository, it’s imported into the GitLab project. The next time that particular package is pulled, it’s pulled from GitLab and not the external repository. Even if the external repository is having connectivity issues and the package is present in the dependency proxy, pulling the package still works, making your pipelines faster and more reliable.
If the package changes in the external repository (for example, a user deletes a version and publishes a new one with different files) the dependency proxy detects it. It invalidates the package, so GitLab pulls the newer one. This ensures the correct packages are downloaded, and helps reduce security vulnerabilities.
The Issue Analytics report now contains information on the number of closed issues in a month to allow for a detailed velocity analysis. With this valuable addition, GitLab users can now gain insights into trends associated with their projects, and improve the overall turn-around time and value delivered to their customers. The Issue Analytics visualization contains a bar chart with the number of issues for each month, with a default time span of 13 months. You can access this chart from the drill-down in the Value Streams Dashboard.
We added a new DORA Performers score panel to the Value Streams Dashboard to visualize the status of the organization’s DevOps performance across different projects. This new visualization displays a breakdown of the DORA score (high, medium, or low) so that executives can understand the organization’s DevOps health top to bottom.
The four DORA metrics are available out-of-the-box in GitLab, and now with the new DORA scores organizations can compare their DevOps performance against industry benchmarks or peers. This benchmarking helps executives understand where they stand in relation to others, and identify best practices or areas where they might be lagging behind.
To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.
From GitLab 16.8, you can specify commands to generate configurations for the following services in the
gitlab.rb file so that plaintext passwords are not exposed:
This means plaintext passwords for Redis no longer need to be stored in gitlab.rb.
patch-id supportTo ensure all changes are reviewed and approved, it’s common to remove all approvals when new commits are added to a merge request. However, rebases also unnecessarily invalidated existing approvals, even if the rebase introduced no new changes, requiring authors to seek re-approval.
Merge request approvals now align to a git-patch-id. It’s a reasonably stable and reasonably unique identifier that enables smarter decisions about resetting approvals. By comparing the patch-id before and after the rebase, we can determine if new changes were introduced that should reset approvals and require a review.
If you have feedback about your experiences with resets now, let us know in issue #435870.
In previous versions of GitLab, viewing file blame required you to access a different page. Now you can view the file blame information directly from the file page.
Improved developer experience, onboarding, and security are driving more development toward cloud IDEs and on-demand development environments. However, these environments might contribute to increased infrastructure costs. You can already configure CPU and memory usage per project in your devfile.
Now you can also set CPU and memory usage per workspace. By configuring requests and limits at the GitLab agent level, you can prevent individual developers from using an excessive amount of cloud resources.
This release adds full support for Kubernetes version 1.28, released in August 2023. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
There are five new abilities available you can use to create custom roles:
Add these abilities, along with other pre-existing custom abilities, to any base role to create a custom role. Custom roles allow you to define granular roles that only give a user the abilities they need to do their jobs, and reduce unnecessary privilege escalation.
Users can be assigned a custom role as the default role they are created with when they are provisioned with SAML SSO. Previously, only static roles could be chosen as the default. This allows automatically provisioned users to be assigned a role that best aligns with the principle of least privilege.
Streaming audit events have been extended to support filtering by sub-group or project at the group level, in addition to the existing support for event type filtering.
This additional filter will allow you to separate out events in your streams to send to different destinations, or to exclude irrelevant sub-groups/projects, ensuring you have the most actionable events for your team to monitor.
Our compliance center is becoming the central destination for understanding compliance posture and managing compliance frameworks. We’re moving framework management into a new tab in the compliance center, as well as adding more exciting capabilities:
Previously, you could configure only top-level group streaming audit events for AWS S3.
With GitLab 16.8, we’ve extended support for AWS S3 to instance-level streaming destinations.
One of several new settings added to scan result policies to aide in compliance enforcement of security policies, branch modification controls will limit the ability to circumvent policies by changing project-level settings.
For each existing or new scan result policy, you can enable Prevent branch modification to take effect for the branches defined within the policy to prevent users from deleting or unprotecting those branches.
You can now use SAML Group Sync to map custom roles to groups of users. Previously, you could only map SAML groups to GitLab’s static roles. This gives more flexibility to customers who use SAML Group Links to manage group membership and member roles.
For those using SAML SSO and SCIM for user account management in GitLab, you can now use SSO to meet the merge request authentication requirement over password-based authentication for approving merge requests.
This method ensures only authenticated users can approve a merge request for security and compliance, without having to use a separate password-based solution.
We are introducing a new landing page for the group-level analytics dashboard. This enhancement ensures a more consistent and user-friendly navigation experience. In the first phase this page includes the Value Streams Dashboard, but it also sets the groundwork for future features, allowing you to personalize your dashboards. These improvements aim to streamline your experience, and provide more flexibility in managing and interpreting your data.
With this release, you can now view the entire hierarchy lineage of a work item instead of just the immediate parent.
Work items include:
You might need to run a report of CI/CD compute minutes used by projects on instance runners for various reasons. However, there wasn’t a simple to use mechanism in GitLab for you to generate a CI/CD compute minutes usage report. With this feature, you can export a report of CI/CD compute minutes used by each project on shared runners as a CSV file.
We’re also releasing GitLab Runner 16.8 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
If you use automation to work with merge requests in CI/CD pipelines, you might have wanted an easier way to fetch a merge request’s description without an API call. In GitLab 16.7 we introduced the CI_MERGE_REQUEST_DESCRIPTION predefined variable, making the description easily accessible in all jobs. In GitLab 16.8 we tweaked the behavior to truncate CI_MERGE_REQUEST_DESCRIPTION at 2700 characters, because very large descriptions can cause runner errors. You can check if the description was truncated with the newly introduced CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED predefined variable, which is set to true when the description was truncated.
Teams can now build, test, and deploy applications on Windows Server 2022.
SaaS runners on Windows allow you to increase your development teams’ velocity in building and deploying applications that require Windows in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.
Try it out today by using saas-windows-medium-amd64 as the tag in your .GitLab-ci.yml file.
As the number of items in the CI/CD catalog continues to expand, it is increasingly challenging for you to locate the CI/CD components released by your teams and available to you. In this release, we are introducing a dedicated Your groups tab, empowering you to effortlessly filter and identify the components associated with your organization. This simplified search process enhances efficiency, as you can more quickly find and use released CI/CD components.
On December 21, 2023, GitLab 16.7 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
As we continue to focus on growing our wider community, we are incredibly happy to see both MVPs nominated by members of the Core team.
Muhammed was nominated for adding support for specifying platform when using Docker images with GitLab Runner. This contribution took 9 months of collaboration and showed Muhammed’s commitment and perseverance when a bug required a follow-up. This solved a popular two-year-old issue. “Great shoutout to the GitLab Runner team” Muhammed said, “for supporting me on bringing a long awaited feature to fruition”. Muhammed is an Automation Engineer at Airtime Rewards, working mainly with Terraform and promoting CI/CD and automation practices within the engineering teams.
Niklas was nominated for his continued contributions and support in many different forms. Today marks exactly 1 year since his last MVP award. Niklas tackles daunting work which proves challenging even for GitLab team members and plays a huge part in maintaining our wider community contributors. Read more in the nomination issue.
Thank you Muhammed and Niklas! 🙌
GitLab Duo Code Suggestions is now generally available!
GitLab Duo Code Suggestions helps teams create software faster and more efficiently, by completing lines of code and defining and generating logic for functions.
Code Suggestions is built with privacy as a critical foundation. Private, non-public customer code stored in GitLab is not used as training data. Learn about data usage when using Code Suggestions.
In the general release, we’ve made Code Suggestions available across several IDEs. Code Suggestions is also now more intuitive and responsive.
GitLab Duo Code Suggestions is free to try subject to the GitLab Testing Agreement until February 15, 2024. Starting today, you can buy Code Suggestions as an add-on to GitLab subscriptions for an introductory price of $9 USD per user/per month. Please contact us to get started with Code Suggestions.
Previously, to create a GitLab Pages project, you needed a domain formatted like name.example.io or name.pages.example.io. This requirement meant you had to set up wildcard DNS records and SSL/TLS certificates. In GitLab 16.7, you can set up a GitLab Pages project without a DNS wildcard. This feature is an experiment.
Removing the requirement for wildcard certificates eases administrative overhead associated with GitLab pages. Some customers can’t use GitLab Pages because of organizational restrictions on wildcard DNS records or certificates.
We welcome feedback related to this feature in issue 434372.
With the Insights report you can analyze patterns over time using customizable charts. The new drill-down capability added to the “Bugs created by priority” and “Bugs created by severity” Insights reports allows you to drill down on the Issue analytics report for deeper analysis.
We plan to include this capability in the other Insight reports as a custom option in a later version.
SAST findings now appear in the merge request Changes view. This makes it easier to see, understand, and fix potential weaknesses during the code review process.
Lines containing SAST issues are marked by a symbol beside the gutter. Select the symbol to see the list of issues, then select an issue to see its details.
We’ve enabled this feature on GitLab.com. We plan to enable the feature flag by default for Self-Managed instances in GitLab 16.8.
GitLab 16.7 sees the Beta release of the CI/CD catalog! The catalog is where you can search for CI/CD components maintained by you, your organization, or the public community. This is the place where DevOps engineers come together to create, contribute, and share reusable pipeline configurations.
Unlike other methods of reusing CI/CD configuration, CI/CD components published in the catalog have an improved experience, and are easily added to your pipeline. We invite you to start testing this new and exciting feature! You can try out components that others have created and shared in the catalog, or create your own components and share them with everyone.
While this is our initial beta release of the feature, we continue to work on making the experience even better. Our goal is to make the CI/CD catalog a fundamental part of the GitLab CI/CD experience.
You can now list your Mastodon handle on the User Profile. With this enhancement we are now supporting a fediverse social network, which will help in advancing ActivityPub for GitLab.
Group descriptions can now contain up to 500 characters. If you try to save a group description with more than 500 characters, a warning message appears stating that the description is too long. Thanks to @freznicek for this community contribution!
The search bar is now more prominent on the search results page. To increase the search bar visibility, the group and project filters have been moved to the left sidebar.
In GitLab 16.7, issues with code have become more discoverable. With advanced search, you can now find issues that contain code snippets and logs in their descriptions.
Until now, GitLab only displayed time in 12 hour format, which could not be changed.
From this release, thanks to the community contribution, you can customize the format used to display time in places like issue lists, overview pages or when setting your status. You can display times as:
2:34 PM.14:34.Thanks to Thorben Westerhuys for this community contribution!
In the following milestone we will audit all timestamps shown across the GitLab product to make them respect the setting.
Administrators can now access the Admin Area in one step, by using a link at the bottom of the left sidebar. Previously, you had to select Search or go to and then select Admin Area. This change should save you time when accessing the Admin Area.
GitLab groups and project migrations done by direct transfer can become stuck for various reasons. In the past, to avoid leaving these migrations in an incomplete state indefinitely, GitLab periodically executed a worker to identify migrations that hadn’t completed within 8 hours. GitLab marked these migrations as timed out.
For large organizations, the migration process can take longer than 8 hours, so this amount of time was not always sufficient to properly determine if a migration was stuck. As a result, this worker might have incorrectly marked a migration as stuck.
In this milestone, instead of using an 8 hour time limit, GitLab now only marks the migration as stuck if the child workers stop working for 24 hours.
Knowing how crucial for our users is to understand the results of the import process, in this milestone we further improved on information presented for imports by direct transfer. We now display import status badges next to GitLab groups and projects on:
The import status badges are:
The Partially completed badge was added in this release and identifies a completed import process that has some items (such as merge requests or issues) not imported.
Groups that an import process was started for have a View details link that shows imported subgroups and projects for that particular group. From there, you can see the list of items that couldn’t be imported (if any) by clicking a See failures link. See failures was released in the last release.
In this milestone we also improved navigation with the breadcrumbs between those pages.
You can now configure GitLab to reopen closed issues when an external participant adds a new comment on an issue by email. This gives you full visibility into ongoing conversations, even after an issue has been resolved.
It also adds an internal comment that mentions the assignees of the issue and creates to-do items for them. This way you can make sure you never miss a follow-up email again.
You can now override the default single-threaded gzip compression library with an alternate compression library of your choice for backups using the COMPRESS_CMD and DECOMPRESS_CMD commands. This allows you to leverage parallel compression libraries to speed up the compression stage of the backup by using the power of modern multi-core processors. The commands include support for passing options to the compression library allowing you to adjust parameters such as compression levels and speed.
In GitLab 16.7, you can now define a network policy with egress rules when you configure the GitLab agent for Kubernetes to support Workspaces. Use this feature for your self-hosted installation where the GitLab instance resolves to a private IP or when a workspace must access a cloud resource on a private IP range.
Who doesn’t love a good emoji to really express yourself? When commenting on items across GitLab, you’ve used our default set of emoji to add reactions, but sometimes those emoji just weren’t enough to express your emotions. Groups can now add custom emoji to use across their projects. Custom emoji allow you to express your true feelings and communicate more clearly with the rest of your team. We can’t wait to see how you’ll react next.
GitLab merge request dependencies are a great way to ensure that code changes that rely on other changes aren’t merged in a way that could break the codebase. Previously, GitLab didn’t allow complex dependency chains, which could result in circular references or deep nesting.
The limitations around dependency hierarchy, and items in the chain, have been removed. Merge request dependencies can now be more complex: a single merge request can be blocked by up to 10 merge requests, and in turn, block to 10 other merge requests. Deeper dependency chains make it possible to represent more complex workflows via dependencies. We’re excited to see how you continue to expand your usage of this feature.
When your approval is required for a merge request, you need to be notified to take action. Some users only want notifications when their approval is required, which is typically done by adding a user by name to review the changes. However, some users want a notification for any merge request they are eligible to approve, even if they aren’t added by name as reviewers.
Enable the Added as approver custom notification level to trigger an email and to-do for each merge request you are eligible to approve. This helps you be aware of merge requests sooner in the process, and take action to get the proposal merged.
If you’re switching from Terraform to OpenTofu, this release of GitLab adds preliminary support for OpenTofu. Because OpenTofu is a fork of Terraform, the MR widget integration, module registry, and GitLab-managed Terraform state work by default. We added support for OpenTofu in the gitlab-terraform helper image to simplify the usage of the GitLab IaC offering.
GitLab continues to support Terraform for the MR widget, module registry, and GitLab-managed Terraform state.
You can now optionally input a new parameter, expires_at, when rotating an access token. This allows you to create a custom expiry date for the token. Previously, each rotation extended the expiration one week from the previous expiry date. This new option provides flexibility in rotation interval.
You can now use the UI to assign a custom role to a new user, or change an existing user’s role to a custom role. You can do this in any part of the UI where you can currently assign or change a user’s role. Previously, you could only do this through the API.
CI/CD variable precedence has been improved to first prioritize variables defined in scan execution policies.
As organizations work to meet compliance requirements, a common need is to ensure that security scanners are enabled in business critical applications.
Scan execution policies allow teams to enforce scanners and to define default and custom CI/CD variables. With this enhancement to CI/CD variable precedence, teams can be confident that regardless of how pipelines are triggered, the variables defined with compliance in mind remain intact.
SAML attribute statements now support the Microsoft SAML attribute format, which is in URL form. Previously, self-managed instance administrators had to manually configure attribute statements, and GitLab.com group owners had to add custom attributes to their SAML responses. This change allows both self-managed GitLab and GitLab.com to work with Microsoft without any manual configuration.
In GitLab 16.2 we released the rich text editor as an alternative to the existing Markdown editing experience. The rich text editor provides a “what you see is what you get” editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.
With GitLab 16.7, we’ve changed the rich text editor to match the behavior with our Markdown editing experience and fix reported bugs. We’ve changed the sorting order in the labels autocomplete modal to be consistent between the Markdown and rich-text editor, addressed a bug in the options returned in the unassign quick action in the rich-text editor, added support for custom emojis, and updated the look and feel of the quick action selection dropdown to be consistent in the two editing experiences, among other improvements.
Previously, the Container Registry relied on the Docker/OCI listing image tags registry API to list and display tags in GitLab. This API had significant performance and discoverability limitations.
This API performed slowly because the number of network requests against the registry scaled with the number of tags in the tags list. In addition, because the API didn’t track publish time, the published timestamp was often incorrect. There were also limitations when displaying images based on Docker manifest lists or OCI indexes, such as for multi-architecture images.
To address these limitations, we introduced a new registry list repository tags API. By updating the user interface to use the new API, the number of requests to the Container Registry is reduced to just one. Publish timestamps are also accurate, and there is more robust support for multi-architecture images.
This feature is available only on GitLab.com. Self-managed support is blocked until the next-generation Container Registry is generally available. To learn more, see issue 423459.
Before this release, you could not rename a project that had a container repository with at least one tag without having first deleted all container images associated with that project.
This was a real problem that forced users to rely on custom scripts to manually delete/move all tags before a different project name could be used, but now you can rename projects on GitLab.com, even if they have container images in the registry!
The value stream analytics report now has a set of filter options for data in the last 30, 60, 90, or 180 days. These new filter options simplify the date selection process, making it more efficient and user-friendly to understand where time is spent during the development lifecycle.
Continuous Vulnerability Scanning is now Generally Available. With CVS enabled, your projects are automatically scanned when advisories are added to the GitLab Advisory Database. If new dependency-related vulnerabilities are identified, vulnerabilities are created automatically.
During the 16.7 release milestone, we enabled the following active checks for browser-based DAST by default:
The new DAST_AFTER_LOGIN_ACTIONS variable enables you to provide a list of actions to be executed after login. This allows for multi step login interactions, for example Azure AD’s “Keep Me Signed In” workflow.
We’ve updated the default ruleset used in GitLab SAST to provide higher-quality results. We analyzed each rule that was previously included by default, then removed rules that did not provide enough value in most codebases.
The rule changes are included in updated versions of the Semgrep-based GitLab SAST analyzer. This update is automatically applied on GitLab 16.0 or newer unless you’ve pinned SAST analyzers to a specific version.
Existing scan results from the removed rules are automatically resolved after your pipeline runs a scan with the updated analyzer.
We’re working on more SAST rule improvements in epic 10907.
artifacts:public CI/CD keyword now generally availablePreviously, the artifacts:public keyword was only available as a default disabled feature for self-managed instances. Now in GitLab 16.7 we’ve made the artifacts:public keyword generally available for all users. You can now use the artifacts:public keyword in CI/CD configuration files to control whether job artifacts should be publicly accessible.
In GitLab 13.0 we introduced the ability to keep the job artifacts from the most recent successful pipeline. Unfortunately, the feature also marked all failed and blocked pipelines as the latest pipeline regardless of whether they were the most recent or not. This led to a buildup of artifacts in storage which had to be deleted manually.
In GitLab 16.7 the bugs causing this unintended behavior are resolved. Job artifacts from failed and blocked pipelines are only kept if they are from the most recent pipeline, otherwise they will follow the expire_in configuration. Affected GitLab.com customers should see artifacts which were inadvertently kept now unlocked and removed after a new pipeline run.
The Keep artifacts from most recent successful jobs setting overrides the job’s artifacts: expire_in configuration and can result in a large number of artifacts stored without expiry. If your pipelines create many large artifacts, they can fill up your project storage quota quickly. We recommend disabling this setting if this feature is not required.
We’re also releasing GitLab Runner 16.7 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
Runners can now generate provenance metadata with a statement that adheres to SLSA 1.0. To enable SLSA 1.0, set the SLSA_PROVENANCE_SCHEMA_VERSION=v1 variable in the .gitlab-ci.yml file. The SLSA version 1.0 statement is planned to become the default version in GitLab 17.0.
On November 16, 2023, GitLab 16.6 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Joe Snyder was awarded GitLab’s 16.6 MVP for consistent contributions across GitLab, including recent merge requests to allow admins to filter runners by version.
Joe was nominated by Miguel Rincon, Staff Frontend Engineer at GitLab. Miguel recognized Joe’s efforts through several required rewrites due to GitLab’s evolving architecture and commented on Joe’s “thoughtful consideration of performance and usability.”
Pedro Pombeiro, Sr. Backend Engineer at GitLab, added that “Joe Snyder drove this change over the finish line after taking over from a former colleague, requiring learning all the context around the problem. He also proved very responsive and patient with our feedback in successive reviews.”
“Joe has been a pleasure to work with,” said Terri Chu, Staff Backend Engineer at GitLab.
Terri highlighted Joe’s ongoing work on emails_enabled changes
over the last (and previous) milestone.
Joe Snyder is a Senior R&D Engineer at Kitware and has been contributing to GitLab since 2021. Our many thanks to Joe for continuing to improve GitLab!
Everyone involved in the software development process can spend a significant amount of time familiarizing themselves with code, epics, issues, and lengthy discussion threads. You can often find yourself slowed down by routine tasks like writing summaries, documentation, tests, or even code. Having an expert at your side that can answer DevSecOps questions without judgment and address follow-ups could help you accelerate the software development process.
GitLab Duo Chat aims to actively address these pain points and accelerate your workflows. Its capabilities include:
GitLab Duo Chat is available on GitLab.com as a Beta feature. It is also integrated into our Web IDE and GitLab Workflow extension for VS Code as Experimental features.
You can also help us mature these features by providing feedback about your experiences with Duo Chat, either within the product or via our feedback issue.
When a GitLab.com user’s primary email address matches an existing verified domain, the user is automatically claimed as an enterprise user. This gives the group Owner more user management controls and visibility into the user’s account. After a user becomes an enterprise user, they can only change their primary email to an email their organization owns as per its verified domains.
In previous versions of GitLab, when forking a repository, the fork always included all branches within the repository. Now you can create a fork with only the default branch, reducing complexity and storage space. Create minimal forks if you don’t need the changes that are currently being worked on in other branches.
The default method of forking will not change and continue to include all branches within the repository. The new option shows which branch is the default, so that you are aware of exactly which branch will be included in the new fork.
There is an increasing scrutiny on code changes that can potentially land in production applications and open businesses up to compliance risk and security vulnerability. With scan result policies, you can ensure unilateral changes cannot be made by enforcing two person approval on all merge requests.
Scan results policies have a new option to target Any merge request which can be paired with defining role-based approvers to ensure each MR for the defined branches require approval by two (or more) users with a given role (Owner, Maintainer, or Developer).
Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_any_merge_request and will be enabled by default in 16.7.
Switchboard, a new self-service portal, is now available for customers and team members to onboard, configure and maintain their GitLab Dedicated instances.
Using Switchboard, you can now make some configuration changes to your GitLab Dedicated instance. This functionality will expand in future releases.
In GitLab 16.1, we announced the release of an exciting experimental feature called CI/CD components. The component is a pipeline building block that can be listed in the upcoming CI/CD catalog.
Today we are excited to announce the Beta availability of CI/CD components. With this release, we have also improved the components folder structure from the initial experimental version. If you are already testing the experimental version of CI/CD components, it’s essential to migrate to the new folder structure. You can see some examples here. The old folder structure is deprecated and we plan to remove it within the next couple of releases.
If you try out CI/CD components, you are also welcome to try the new CI/CD catalog, currently available as an experimental feature. You can search the Global CI/CD catalog for components that others have created and published for public use. Additionally, if you create your own components, you can choose to publish them in the catalog too!
CI/CD variables are a fundamental part of GitLab CI/CD, and we felt that we could offer a better experience for working with variables from the settings UI. So in this release we’ve updated the UI to use a new drawer that improves the flow of adding and editing CI/CD variables.
For example, the masking validation used to only happen when you tried to save the CI/CD variable, and if it failed you’d have to restart from scratch. But now with the new drawer, you get real time validation so you can adjust on the fly without needed to redo anything!
Your feedback for this change is always valued and appreciated.
Operators of self-managed runner fleets need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. Now, with the Runner Fleet Dashboard - Admin View (Beta), you have actionable insights to help you quickly answer critical fleet management and developer experience questions, starting with instance runners. These include answers to questions like which runners have errors, the performance of the runner queues for CI job execution, and which runners are most actively used. Ultimate customers can enable this feature independently, but are encouraged to participate in the early adopter’s program.
Previously, users saw many archived projects in their project search results. This was problematic, especially when archived projects took up many of the top results. We now filter out archived projects by default, and users can select Include archived to see all projects.
Previously, the names of private groups were visible to all users when accessing the Groups tab of a project’s or group’s members page. To enhance security, we are now masking private groups’ name and source from users who are not members of the shared group, shared project, or invited group. Instead, this information will be displayed as Private.
Previously, when migrating GitLab projects and groups by direct transfer had completed and some items (such as a merge requests or issues) were not successfully imported, you could select a Details button on the page listing imported groups and projects and see related errors there.
However, a list of errors is not helpful to understand how many items in total, and which items in particular, were not imported. Having this information is crucial to understanding the results of the import process.
In this release, we replaced the Details button with a See failures link. Selecting the See failures link takes you to a new page listing all items that failed to import for a given group or project. For each item that wasn’t imported, you can see:
iid).The 16.0 release introduced a new navigation experience, which became the default for all users on June 2, 2023. In subsequent milestones, many improvements were made based on a wealth of user feedback. The ability to fall back to the old navigation has now been removed. More exciting changes are planned for the navigation, but for now, all users have a consistent navigation experience.
As a recap, with the new GitLab navigation, you can:
When GitLab Silent Mode is enabled, it blocks all major outbound traffic such as notification emails, integrations, webhooks, and mirroring from a GitLab instance. This allows you to perform testing against a GitLab site without generating traffic towards users and other integrations. You can use Silent Mode to test a restored backup or a promoted Geo DR site without impacting your primary GitLab site or your end users.
In GitLab 16.6, you can use the cluster UI integration on your environment page to determine the status of currently running applications without leaving GitLab. Previously, the status was updated by a one-time request when the UI loaded, which made tracking deployment progress unwieldy. The current version of GitLab upgrades the underlying connection to use the Kubernetes watch API for the Flux reconciliation and Pod statuses, and provides near real-time updates of the cluster state in the GitLab UI.
From GitLab version 16.4, you can connect to a Kubernetes cluster from a local terminal using the agent for Kubernetes and a personal access token. In the initial version, setting up the local cluster configuration required several commands and a long lived access token. In the past month, we worked to streamline and improve the security of the set up process by extending the GitLab CLI.
The GitLab CLI can now list the agent connections available from a GitLab project checkout directory or the specified project. You can set up the connection through a selected agent with a dedicated command. When kubectl or any other tool needs to authenticate with the cluster, the GitLab CLI generates a temporary, restricted token for the signed-in user.
One of several new settings being added to scan result policies to aide in compliance enforcement of security policies, this control will limit the ability to leverage project-level settings to circumvent policies.
For each existing or new scan result policy, you can enable Prevent pushing and force pushing to take effect for the branches defined within the policy to prevent users from circumventing the merge request flow to push changes directly to a branch.
Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_policies_block_force_push and will be enabled by default in 16.7.
Building on our integrations with external logging or data aggregation tools, you can now select AWS S3 as a destination for audit event streams for top-level groups. This feature provides relevant information for an easier and more trouble-free integration.
Previously, you had to use custom HTTP headers to try to build a request that AWS S3 would accept. This method was prone to errors and could be difficult to troubleshoot.
Previously, external status checks on MRs continued to poll the external URL until they received either a successful or failed response. This could result in some status checks seeming to hang in an unresponsive state.
Now, a 2 minute timeout has been incorporated so that you can manually retry the status check after 2 minutes if you are not getting any response from the external system.
Previously, the vulnerability report allowed you to filter by a static list of GitLab-supported tool types, followed by a dynamic list of custom scanners. With this release, you can now select tool type grouped by analyzer.
GitLab administrators and group Owners can choose if they want to enforce an expiry date for service accounts. Previously, service account tokens had to expire within a year, in line with personal, project, and group access token expiration limits. This allows administrators and group Owners to choose the balance between security and ease of use that best aligns with their goals.
You can use the GitLab Package Registry to publish and download your project’s NuGet packages. By default, you can publish the same package name and version multiple times.
However, you might want to prevent duplicate uploads, especially for releases. In this release, GitLab has expanded the group setting for the Package Registry so you can allow or deny duplicate package uploads.
You can adjust this setting with the GitLab API, or from the UI.
The GitLab Package Registry now supports uploading Maven packages with basic HTTP authentication. Previously, you could use basic HTTP authentication only to download Maven packages. This inconsistency made it difficult for developers to configure and maintain authentication for their project.
Publishing artifacts with sbt is not supported, but issue 408479 proposes to add this feature.
Container scanning results may include findings which the vendor has evaluated and decided to not fix. To allow you to focus on actionable findings, you can now exclude such findings. For configuration options please refer to the GitLab documentation.
When you export information from the vulnerability report, the CVSS Vector information is now included. This additional data helps you analyze and triage vulnerabilities outside GitLab.
Dependency Scanning and License Scanning now support SBT projects using Java 21.
During the 16.6 release milestone, we enabled the following active checks for browser-based DAST by default:
Teams can now seamlessly create, test, and deploy applications for the Apple ecosystem on macOS 14 and Xcode 15.
SaaS runners on macOS allow you to increase your development teams’ velocity in building and deploying applications that require macOS in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.
Try it out today by using macos-14-xcode-15 as the image in your .GitLab-ci.yml file.
We’re also releasing GitLab Runner 16.6 today! GitLab Runner is the lightweight, highly-scalable 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.
image.entrypoint in the Kubernetes executorThe list of all changes is in the GitLab Runner CHANGELOG.
On October 22, 2023, GitLab 16.5 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Thorben was recognized for ongoing work on his merge request to add a user preference to show times in 24-hour format. This feature is planned for 16.6 and will give users the choice between 12-hour and 24-hour time formats.
Magdalena Frankiewicz, Product Manager at GitLab, nominated Thorben and noted the issue for this feature has been open for 7 years with over 190 upvotes. Peter Leitzen, Staff Backend Engineer at GitLab, also highlighted Thorben’s work to refactor backend code related to time format.
Thorben is CTO of LUUCY, a 3D web platform bringing together high resolution geo data. He is a former CTO of cividi, a geo spatial data consultancy for urban planning related topics.
Thank you to Thorben and the rest of the GitLab Community for contributing 🙌
The Compliance Center now includes a new tab for the standards adherence report. This report initially includes a GitLab best practices standard, showing when the projects in your group are not meeting the requirements for the checks included in the standard. The three checks shown initially are:
The report contains details on the status of each check on a per project basis. It will also show you when the check was last run, which standard the check applies to, and how to fix any failures or problems that might be shown on the report. Future iterations will add more checks and expand the scope to include more regulations and standards. Additionally, we will be adding improvements to group and filter the report, so you can focus on the projects or standards that matter most to your organization.
Some projects use multiple long-term branches for development, like develop and qa. In these projects, you might want to keep main as the default branch since it represents the production state of the project. However, development work expects merge requests to target develop or qa. Target branch rules help ensure merge requests target the appropriate branch for your project and development workflow.
When you create a merge request, the rule checks the name of the branch. If the branch name matches the rule, the merge request pre-selects the branch you specified in the rule as the target. If the branch name does not match, the merge request targets the default branch of the project.
Long-running issues with many threads can be challenging to read and track. You can now resolve a thread on an issue when the topic of discussion has concluded.
In 16.4, we released Fast-forward merge trains, and as a continuation, we want to ensure we support all merge methods. Now, if you want to ensure your semi-linear commit history is maintained you can use semi-linear fast-forward merge trains.
The popularity of epics in GitLab continues to grow. Previously, finding epics was a little more difficult than other content types. With this release, you can now search and view results for epics when you use advanced search.
.deb Linux packages have switched from gzip to xz compression,
resulting in smaller package sizes. This change might result in slower unpacking times during installation./opt/gitlab/embedded/selinux/rhel/7/ to /opt/gitlab/embedded/selinux to reflect that the module isn’t only for RHEL 7.With the GitLab for Jira Cloud app, you can connect GitLab and Jira Cloud to sync development information in real time. You can view this information in the Jira development panel. Previously, when a reviewer was assigned to a merge request, the reviewer information was not displayed in the Jira development panel. With this release, the reviewer name, email, and approval status are displayed in the Jira development panel when you use the GitLab for Jira Cloud app.
We’ve heard your feedback that on the left sidebar, it can be hard to find the search button and to change between things like projects and preferences. In this release, we’ve made the button more prominent. This aids discoverability as well as streamlining workflows into a single touch point.
You can try it out by selecting the Search or go to… button or with a keyboard shortcut by typing / or s.
You can use release events to monitor release objects and react to changes. Previously, a webhook was only triggered when a release was created or updated. In heavily regulated industries, deleting releases is a crucial event that must be monitored and followed up. With GitLab 16.5, a webhook is now also triggered when a release is deleted.
We’ve redesigned Service Desk issues list to load faster and more smoothly. It now matches more closely the regular issues list. Available features include:
You can now trigger bulk resync or reverify for any data component managed by Geo, through buttons in the Geo admin UI. Selecting the button will apply the operation to all data items related to the respective component. Before, this was only possible by logging into the Rails console. These actions are now more accessible, and the experience of troubleshooting and applying large scale changes that require a full resync or reverify of specific components, such as moving storage locations, is improved.
The GitLab backup and restore feature now supports storing repository data in object storage. This update improves performance by eliminating the intermediate steps used to create a large tarball, which needs to be manually stored in an appropriate location.
With this update, repository backups get stored in an object storage location of your choice (Amazon S3, Google Cloud Storage, Azure Cloud Data Storage, MinIO, etc.). This change eliminates the need to manually move data off of your Gitaly instance.
Deployments in regulated industries are a central topic of compliance. In previous releases, deployment approvals were not part of audited events, which made it difficult to tell when and how approval rules changed.
GitLab now ships with a new set of audit events for deployment approval and approval rule changes. These events fire when deployment approval rules change, or when approval rules for protected environments change.
Previously, group Owners had no way to programmatically delete SAML or SCIM identities. This made it difficult to troubleshoot issues with the user provisioning and sign-in processes. Now, group Owners can use new endpoints to delete these identities.
Thank you jgao1025 for your contribution!
The compliance violations report can contain a lot of information. Previously, you could only view the information in the GitLab UI. This was fine for individual issues, but could be tricky if you needed to, for example:
In GitLab 16.5, you can now export a list of the items included in the compliance violations report in CSV format.
The permissions to manage group members and project access tokens have been added to the custom roles framework. You can add these permissions to any base role to create a custom role. By creating custom roles with only the permissions needed to accomplish a particular set of tasks, you do not have to unnecessarily assign highly privileged roles such as Maintainer and Owner to users.
Previously, you could configure only top-level group streaming audit events for Google Cloud Logging.
With GitLab 16.5, we’ve extended support for Google Cloud Logging to instance-level streaming destinations.
Administrators can now configure a locked user policy for their instance by choosing the number of unsuccessful sign-in attempts, and how long the user is locked for. For example, five unsuccessful sign-in attempts would lock a user for 60 minutes. This allows administrators to define a locked user policy that meets their security and compliance needs. Previously, the number of sign-in attempts and locked user time period were not configurable.
Previously, you had to delete HTTP headers added to audit event streaming destinations, even if you only wanted to deactivate them temporarily.
With GitLab 16.5, you can use the Active checkbox in the GitLab UI to toggle each header on and off individually. You can use this to:
You can now use a new REST API endpoint at user/personal_access_tokens to create a new personal access token for the currently authenticated user. This token’s scope is limited to k8s_proxy for security reasons, so you can use it to only perform Kubernetes API calls using the agent for Kubernetes. Previously, only instance administrators could create personal access tokens through the API.
As a user, you require the ability to group vulnerabilities so that you can more efficiently triage vulnerabilities. With this release, you are able to group by severity or status. This will help you better answer questions like how many confirmed vulnerabilities are in a group or project, or how many vulnerabilities still need to be triaged.
From GitLab 16.5, you can export individual wiki pages as PDF files. Now, sharing team knowledge is even more seamless. Exporting a wiki to PDF can be used for a variety of use cases. For example, to provide a copy of technical documentation that is kept in a wiki or share information in a wiki with project status. Gone is the need to leverage alternative tools to convert Markdown files to PDF, since in some organizations, using these tools is prohibited, creating another challenge. Thank you to JiHu for contributing this feature!
You can now add a child item for a task, objective, or key result by using the /add_child quick action.
With this release, you can link tasks and OKRs as “related,” “blocked by,” or “blocking” to provide traceability between dependent and related work items.
When we migrate epics and issues to the work item framework, you will be able to link across all these types.
You can now set a parent item for a task, objective, or key result by using the /set_parent quick action.
During the 16.5 release milestone, we enabled the following active checks for browser-based DAST by default:
A rate limit for the project/:id/jobs API endpoint was added recently,
defaulting to 600 requests per minute per user. As a follow up iteration, we are making this limit
configurable, enabling instance administrators to set the limit that best matches their requirements.
We’re also releasing GitLab Runner 16.5 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On September 22, 2023, GitLab 16.4 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Kik has been instrumental in designing and beginning the implementation of ActivityPub support in GitLab. His original deeply detailed architecture plan has been embraced by our product team and now lives as an epic in the GitLab project. The first MR implementing this code was recently merged, followed by a documentation addition.
As support for this large feature grows, Kik has shown himself to be a personification of the GitLab Values of Collaboration, Iteration and Transparency!
Kik has been a part of the GitLab community for many years, logging his first issue over 7 years ago. He’s chosen to become a bit more active over the last few months. When asked about his contributions, he stated:
If there is anything to highlight, it’s probably how enabling GitLab is, allowing to see its source code and tinker with it, while being welcoming to contributions, no matter how ambitious they are. :)
He has also chosen to help pioneer our sustainability efforts by choosing to have trees planted in his name instead of opting for swag. 🌳
Thank you, Kik, for choosing to help build GitLab and being a part of our amazing community! 🙌
Group Owners or administrators can now create and remove custom roles using the UI under the Roles and Permissions menu. To create a custom role, you add permissions on top of an existing base role. Currently, there are a limited number of permissions that can be added to a base role, including granular security permissions, the ability to approve merge requests, and view code. Each milestone, new permissions will be released that can then be added to existing permissions to create custom roles.
Previously, it was not possible to create a workspace for a private project. To clone a private project, you could only authenticate yourself after you created the workspace.
With GitLab 16.4, you can create a workspace for any public or private project. When you create a workspace, you get a personal access token to use with the workspace. With this token, you can clone private projects and perform Git operations without any additional configuration or authentication.
Allowing developers access to Kubernetes clusters requires either developer cloud accounts or third-party authentication tools. This increases the complexity of cloud identity and access management. Now, you can grant developers access to Kubernetes clusters using only their GitLab identities and the agent for Kubernetes. Use traditional Kubernetes RBAC to manage authorizations within your cluster.
Together with the OIDC cloud authentication offering in GitLab pipelines, these features allow GitLab users to access cloud resources without dedicated cloud accounts without jeopardizing security and compliance.
In this first iteration of cluster access, you must manage your Kubernetes configuration manually. Epic 11455 proposes to simplify setup by extending the GitLab CLI with related commands.
When reviewing a list of dependencies, it is important to have an overall view. Managing dependencies at the project level is problematic for large organizations that want to audit their dependencies across all their projects. With this release, you can see all dependencies at the project or group level, including subgroups. This feature is now available by default.
Some vulnerabilities need to be addressed in bulk. Whether they are false positives or no longer detected, it’s important to minimize the noise and triage vulnerabilities with ease. With this release you can bulk change the status and make a comment for multiple vulnerabilities from a group or project Vulnerability Report.
Some organizations want to give their security teams the least amount of access necessary so they can adhere to the Principle of Least Privilege. Security teams should not have access to write code updates, but they must be able to approve merge requests, view vulnerabilities, and update a vulnerability’s status.
GitLab now allows users to create a custom role based on the access of the Reporter role, but with the added permissions of:
read_dependency).read_vulnerability).admin_merge_request).admin_vulnerability).We plan to remove the ability to change the status of a vulnerability from the Developer role for all tiers in 17.0, as noted in this deprecation entry. Feedback on this proposed change can be shared in issue 424688.
Fast-forward merge is a common and popular merge method which avoids merge commits, but requires more rebasing. Separately, Merge Trains are a powerful tool to help with some of the greater challenges related to frequently merging into the main branch. Unfortunately, before this release you could not use merge trains and fast-forward merge together.
In this release, self-managed admins can now enable both Fast-forward merge and merge trains in the same project. You can get all the benefits of merge trains, which ensure all your commits work together before merging, with the cleaner commit history of fast forward merges!
To enable the Fast-forward merge trains, locate the feature flag fast_forward_merge_trains_support, which has been disabled by default, and enable it.
id_token globally and eliminate configuration for individual jobsIn GitLab 15.9 we announced the deprecation of older versions of JSON web tokens in favor of id_token. Unfortunately, jobs had to be modified individually to accommodate this change. To enable a smooth transition to id_token, beginning from GitLab 16.4, you can set id_tokens as a global default value in .gitlab-ci.yml. This feature automatically sets the id_token configuration for every job. Jobs that use OpenID Connect (OIDC) authentication no longer require you to set up a separate id_token.
Use id_token and OIDC to authenticate with third party services. The required aud sub-keyword is used to configure the aud claim for the JWT.
With GitLab 16.4, Elasticsearch index integrity is generally available for all GitLab users. Index integrity helps detect and fix missing repository data. This feature is automatically used when code searches scoped to a group or project return no results.
To provide as many opportunities for automation and integration with third-party systems as possible, we have added support for creating webhooks that trigger when a user adds or revokes an emoji reaction.
You could use the new webhook, for example, to send an email when users react to issues or merge requests with emoji.
When creating a custom role, you can now use the member roles API to add a name (required) and description (optional). Any existing custom roles have been given the name Custom, and you can use the API to change a custom role’s name to a name of your choosing.
GitLab can send messages to Slack workspace channels for certain GitLab events. With this release, you can now trigger Slack notifications for group mentions in public and private contexts in:
We recently turned a few hardcoded import limits into configurable application settings to allow self-managed GitLab administrators to adjust these limits according to their needs.
In this release, we’ve added the timeout for decompressing archived files as a configurable application setting.
This limit was hardcoded at 210 seconds. On GitLab.com, and for self-managed installations by default, we’ve set this limit to 210 seconds. Both self-managed GitLab and GitLab.com administrators can adjust this limit as needed.
Service Desk is one of the most meaningful connections between your business and your customers. Now you can use your own custom email address to send and receive emails for Service Desk. With this change, it is much easier to maintain brand identity and instill customer confidence that they are communicating with the correct entity.
This feature is in Beta. We encourage users to try Beta features and provide feedback in the feedback issue.
Geo now supports unified URLs on Cloud Native Hybrid sites, which means that Cloud Native Hybrid sites can share a single external URL with the primary site. This delivers a seamless GitLab UI and Git developer experience for your remote teams who can be automatically directed to the optimal Geo secondary site based on their location using a single common URL. With this update, unified URLs are now supported across all GitLab reference architectures.
Geo adds the ability to verify object storage when object storage replication is managed by GitLab. To protect your object storage data against corruption, Geo compares the file size between the primary and secondary sites. If Geo is part of your disaster recovery strategy, and you enable GitLab-managed object storage replication, this protects you against data loss. Additionally, it also reduces the need to copy data that may already be present on a secondary site. For example, when adding an old primary back as a secondary site.
environment keyword in downstream pipelinesIf you need to trigger a downstream pipeline from a CI/CD pipeline job, you can use the trigger keyword. To enhance your deployment management, you can now specify an environment with the environment keyword when you use trigger. For example, you might trigger a downstream pipeline for the main branch on your /web-app project with environment name dev and a specified environment URL.
Previously, when you ran separate pipelines for CI and CD and used the trigger keyword to start the CD pipeline, specifying environment details was not possible. This made it hard to track deployments from your CI project. Adding support for environments simplifies deployment tracking across projects.
Security policies enforce scanners to run in GitLab projects, as well as enforce MR checks/approvals to ensure security and compliance. With branch exceptions, you can more granularly enforce policies and exclude enforcement for any given branch that is out of scope. Should a developer create a development or test branch that is unintentionally affected by heavy-handed enforcement, they can work with security teams to exempt the branch within the security policy.
For scan execution policies, you can configure exceptions for the pipeline or schedule rule type. For scan result policies, you can specify branch exceptions for the scan_finding or license_finding rule type.
Group and project access tokens are frequently used for automation. It is important that administrators and group Owners are notified when one of these tokens is close to expiry, so interruptions are avoided. Administrators and group Owners now receive a notification email when a token is seven days or less away from expiry.
A user will get an email notification seven days before their group or project access expires. This only applies if there is an access expiration date set. Previously, there were no notifications when access expired. Advance notice means you can contact your GitLab administrator to ensure continuous access.
Browser-based DAST active check 22.1 has been enabled by default. It replaces ZAP check 6, which has been disabled. Check 22.1 identifies “Improper limitation of a pathname to a restricted directory (Path traversal)”, which can be exploited by inserting a payload into a parameter on the URL endpoint, allowing for arbitrary files to be read.
Operational Container Scanning can now access and scan images from private container registries. OCS uses the image pull secrets to access private registry containers.
Thanks to a community contribution from Weyert de Boer, GitLab Dependency and License Scanning now support analyzing pnpm projects using v6.1 lockfile format.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.4 release milestone:
Security.Misc.IncludeMismatch rule. See the CHANGELOG for further details.If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves.
In GitLab 16.4, we’ve enabled Advanced Vulnerability Tracking for new languages and analyzers. In addition to its existing coverage, advanced tracking is now available for:
This builds on previous expansions and improvements released in GitLab 16.3. We’re tracking further improvements in epic 5144.
These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.
We’ve added an API that allows you to download a CycloneDX SBOM, which lists all the components detected in a CI pipeline. This includes both application-level dependencies and system-level dependencies.
Users with the Maintainer role for a group can now view details for group runners. Users with this role can view group runners to quickly determine which runners are available, or validate that automatically created runners were registered successfully to the group namespace.
Teams can now seamlessly create, test, and deploy applications for the Apple ecosystem on macOS 13.
SaaS runners on macOS allow you to increase your development teams’ velocity in building and deploying applications that require macOS in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.
We’re also releasing GitLab Runner 16.4 today! GitLab Runner is the lightweight, highly-scalable 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.
gitlab-runner-helper terminated during cache downloadingThe list of all changes is in the GitLab Runner CHANGELOG.
On August 22, 2023, GitLab 16.3 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Thomas has contributed 15 merge requests to the GitLab agent for Kubernetes Helm chart in the last month!
Thomas made the chart more mature in terms of security and observability, made it simpler to troubleshoot issues with agentk, and improved the CI/CD pipeline to check for breaking changes.
As a security engineer, Thomas enjoys collaborating with the team to provide a more secure default deployment of the GitLab agent. Thomas expressed thanks for all the timely reviews and feedback, which team members were more than happy to provide.
Thank you Thomas, your contributions are hugely appreciated! 🙌
We would also like to take the opportunity to thank Shane Maglangit and Batuhan Apaydın for their great contributions.
The Value Streams Dashboard has been enhanced with new metrics: Merge request (MR) throughput and Total closed issues (Velocity). In GitLab, MR throughput is a count of the number of merge requests merged per month, and Total closed issues is the number of flow items closed at a point in time.
With these metrics, you can identify low or high productivity months and the efficiency of merge request and code review processes. You can then gauge whether the Value Stream delivery is accelerating or not.
Over time, the metrics accumulate historical data from MRs and issues. Teams can use the data to determine if delivery rates are accelerating or need improvement, and provide more accurate estimates or forecasts for how much work they can deliver.
To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.
With Workspaces, you can create reproducible, ephemeral, cloud-based runtime environments. Since the feature was introduced in GitLab 16.0, the only way to use a workspace was through the browser-based Web IDE running directly in the environment. The Web IDE, however, might not always be the right tool for you.
With GitLab 16.3, you can now securely connect to a workspace from your desktop with SSH and use your local tools and extensions. The first iteration supports SSH connections directly in VS Code or from the command line with editors like Vim or Emacs. Support for other editors such as JetBrains IDEs and JupyterLab is proposed in future iterations.
In previous releases, you probably used kubectl or another third-party tool to check the status of your Flux deployments. From GitLab 16.3, you can check your deployments with the environments UI.
Deployments rely on Flux Kustomization and HelmRelease resources to gather the status of a given environment, which requires a namespace to be configured for the environment. By default, GitLab searches the Kustomization and HelmRelease resources for the name of the project slug. You can customize the name GitLab looks for in the environment settings.
Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. These new filters and filter updates will streamline your workflows:
new_needs_triage allows you to filter only new vulnerabilities that need to be triaged.You can now see security findings directly in Visual Studio Code (VS Code), just as you would in a merge request.
You could already monitor the status of your CI/CD pipeline, watch CI/CD job logs, and move through your development workflow in the GitLab Workflow panel. Now, after you create a merge request for your branch, you can also see a list of new security findings that weren’t previously found on the default branch.
This new feature is part of GitLab Workflow for VS Code. Security scan results are pulled from an API, so this feature is available to developers using GitLab.com or self-managed instances running GitLab 16.1 or higher.
needs keyword with parallel jobsThe needs keyword is used to define dependency relationships between jobs. You can use the keyword to configure jobs to be dependent on specific earlier jobs instead of following stage ordering. When the dependent jobs complete, the job can start immediately, speeding up your pipeline.
Previously, it was impossible to use the needs keyword to set parallel matrix jobs as dependent, but in this release, we have enabled the ability to use needs with parallel matrix jobs too. You can now define a flexible dependency relationship to parallel matrix jobs, which can help speed up your pipeline even more! The earlier your jobs can start, the earlier your pipeline can finish!
Having recently upgraded all of our Linux SaaS runners, we are now introducing xlarge and 2xlargeSaaS runners on Linux. Equipped with 16 and 32 vCPUs respectively and fully integrated with GitLab CI/CD, these runners will allow you to build and test your application faster than ever before.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
Secrets stored in Azure Key Vault can now easily be retrieved and used in CI/CD jobs. Our new integration simplifies the process of interacting with Azure Key Vault through GitLab CI/CD, helping you streamline your build and deploy processes!
You can now opt to include or exclude archived projects from search results. By default, archived projects are excluded. This feature is available for project search in GitLab. Support for other global search scopes is proposed in future releases.
Application setting changes at an instance, project, and group level are now recorded in the audit log, along with which user made the change. This improves auditing of application settings for both self-managed and SaaS.
Until now, the BitBucket Server importer did not import pull request (PR) reviewers and instead categorized them as participants. Information on PR reviewers is important from an audit and compliance perspective.
In GitLab 16.3, we added support for correctly importing PR reviewers from BitBucket. In GitLab, they become merge request reviewers.
Hardcoded limits exist for both migration by direct transfer and by importing export files.
In this release, we’ve made some of these limits configurable in application settings to allow self-managed GitLab administrators to adjust them according to their needs:
We’ve also added a new
maximum decompressed file size for imported archives
application setting, which replaces the validate_import_decompressed_archive_size feature flag. This limit was hardcoded to 10 GB. On GitLab.com, we’ve set this limit to 25
GB.
With these new application settings, both self-managed GitLab and GitLab.com administrators can adjust these limits as needed.
With the new navigation enabled, you can now select one of five different color themes, and choose the light or dark variety for each. Use themes to identify different environments or choose your favorite color.
Until now, migrating groups and projects by direct transfer had a 90 minute export timeout. This limit effectively excluded large projects from being migrated, because only projects that could be migrated in under 90 minutes were allowed.
The upper limit for the overall migration timeout is 4 hours, and so the 90 minutes export timeout was not necessary. In this milestone, the limit was removed, allowing larger projects to be migrated.
GitLab SAML Group Sync now supports the Azure AD (now known as Entra ID) overage claim, which allows a user to have over 150 groups associated with them. The previous maximum was 150 groups. For more information, see Microsoft group overages.
Geo is now able to detect and correct data corruption of group wikis at rest and in transit. If you use Geo as part of your disaster recovery strategy, this helps to protect you against data loss in the event of a failover.
You can now see in the UI if your CODEOWNERS file has syntax or formatting errors. Being able to specify code owners offers great flexibility, allowing multiple file locations, sections, and rules to be configured by users. With this new syntax validation, errors in your CODEOWNERS file will be surfaced in the GitLab UI, making it easy to spot and fix issues. The following errors will be surfaced:
Previously, the CODEOWNERS file didn’t validate the information being entered into the file. This could lead to creating:
This release adds full support for Kubernetes version 1.27, released in April 2023. If you use Kubernetes, you can now upgrade your clusters to the most recent version and take advantage of all its features.
You can read more about our Kubernetes support policy and other supported Kubernetes versions.
If you used feature flags in previous versions of GitLab, you might have noticed that long feature flag names were truncated. This made it difficult to quickly differentiate similar feature flag names.
In GitLab 16.3, the entire feature flag name is shown. Long names wrap across multiple lines, if needed.
Previously, audit event streaming destinations were assigned by the destination URL. This could lead to confusion when you set up multiple streams for one group or instance, because you had to expand the destination in the UI to see what filters and custom headers had been applied.
With GitLab 16.3, you can now name audit event streaming destinations to help identify and differentiate them when you have multiple streaming destinations defined.
GitLab surfaces vulnerabilities that contain relevant information, however, sometimes it is unclear where to start. It takes time to research and synthesize information that is surfaced within the vulnerability record. Moreover it can be difficult to figure out how to fix a given vulnerability. With this Beta release, you can click a button to get an explanation and recommendation on how to mitigate the vulnerability, generated by AI.
To facilitate the growth of compliance-related features beyond reporting and into management, the Compliance reports section of GitLab was renamed to reflect the expanding scope of the area.
From GitLab 16.3, Compliance reports are known as Compliance center.
A scan result policy is a type of security policy you use to evaluate and block merge requests if particular rules are violated. Approvers may review and approve the change, or work with their development teams to address any issues (such as addressing critical security vulnerabilities).
Previously, we compared vulnerabilities in the latest source and target branches to detect any new violations of policy rules. But, this might not capture vulnerabilities detected from scans running as a result of various pipeline sources. To increase accuracy, we are now comparing the latest completed pipelines for each pipeline source (with the exception of parent/child pipelines). This will ensure a more comprehensive evaluation and reduce the cases where approvals are required when it may be unexpected.
In GitLab 16.2, we introduced instance-level audit event streaming. However, no filters were available to apply to these streams.
In GitLab 16.3, you can now apply filters by audit event type to instance-level audit event streams. With the addition of these filters in the UI, you can capture a subset of audit events to send to each streaming location, focusing only on the events that are relevant for you.
Security bot users will be created to support managing background tasks, and to enforce security policies for all newly created or updated security policy project links. This will ease the process for security and compliance team members to configure and enforce policies, specifically removing the need for security policy project maintainers to also maintain Developer access in development projects. Security policy bot users will also make it much clearer for users within an enforced project when pipelines are executed on behalf of a security policy, as this bot user will be the pipeline author.
When a security policy project is linked to a group or subgroup, a security policy bot will be created in each project in the group or subgroup. When a link is made to a group, subgroup, or an individual project, a security bot user will be created for the given project or for any projects in the group or subgroup. Any groups, subgroups, or projects that already have a link to a security policy project will be unaffected at this time, but users may re-establish any existing links to take advantage of this feature. In GitLab 16.4, we plan to enable security bots on all projects hosted on GitLab.com that have existing security policy project links.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.3 release milestone:
toolExecutionNotifications of level error. See the CHANGELOG for further details.If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
GitLab Dependency and License Scanning now support analyzing Java v21 Maven lock files.
You can now use tags to specify which runners you wish to use for on-demand DAST scans. Prior to 16.3, you could configure DAST scans using private runners via CI configuration files. This UI-based configuration enables efficient UI-configuration for managing DAST scans.
GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves. We’ve released two improvements in GitLab 16.3:
This builds on previous expansions and improvements released in GitLab 16.2. We’re tracking further improvements, including expansion to more languages, better handling of more language constructs, and improved tracking for Python and Ruby, in epic 5144.
These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.
We’ve integrated Secret Detection with Postman to better protect customers who use Postman in their GitLab projects.
Secret Detection searches for Postman API keys. If a key is exposed in a public project on GitLab.com, GitLab sends the leaked key to Postman. Postman verifies the key, then notifies the owner of the Postman API key.
This integration is on by default for projects that have enabled Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently only available in Ultimate projects.
See the Postman blog post about this integration for further details.
Pipeline names defined with the workflow:name keyword are now accessible via the predefined variable $CI_PIPELINE_NAME.
We’re also releasing GitLab Runner 16.3 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On July 22, 2023, GitLab 16.2 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Xing Xin was recognized for a recent merge request to use quarantined repo for conflict detection. Karthik Nayak, a Sr. Backend Engineer at GitLab, noted: “Using quarantined repositories allows for avoiding stale objects in git repositories if an operation fails midway. Xing was able to recognize an RPC where we could introduce a quarantine repository and also responded to feedback with good pointers and was able to convince us around some questions with good knowledge about the codebase.”
Xing has been contributing to GitLab and the Gitaly project since 2020. A bytedancer from ByteDance, Xing also spends time in Alibaba Cloud and AntGroup, focusing on code hosting and engineer efficiency. Xing added that the “GitLab community inspired me a lot for both the best practices of managing code and the comments from all the kind reviewers. Hope to grow together with the community.”
Missy Davies is one of the newest members of the GitLab Heroes program. She was recognized for many recent contributions across GitLab projects, including several merge requests for the Pipeline Execution and Environments groups.
Missy has also been an active member of the GitLab Contributor Community and regularly engages in community events, office hours, and on the Discord server. Both Lee Tickett and Marco Zille, members of the GitLab Community Core Team, highlighted Missy’s engagement with the wider community. Lee added that Missy has been “living our values”.
Missy shared that she has found great enjoyment in her growing involvement in the world of open source at GitLab. She values the strong sense of community, the continuous learning opportunities, and shared passion for open source principles. As a backend developer with experience working with Ruby on Rails and Python, Missy has been an impactful GitLab contributor since 2022.
A big thanks to all of our community contributors this past release 🙌
GitLab 16.2 features an all-new rich text editing experience! This new capability is available for everyone, as an alternative to the existing Markdown editing experience.
For many, using the plain text editor for comments or descriptions is a barrier to collaboration. Remembering the syntax for image references or working with long tables can be tedious even for those who are relatively experienced with the syntax. The rich text editor aims to break down these barriers by providing a “what you see is what you get” editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.
The rich text editor is now available in all issues, epics and merge requests. We plan to make it available in more places across GitLab soon. You can follow our progress here.
We are proud of the new editing experience and can’t wait to see what you think. Please try the new rich text editor and let us know about your experience in this issue.
By default, Flux synchronizes Kubernetes manifests at regular intervals. Triggering a reconciliation immediately when a manifest changes by default requires additional configuration. With the GitLab agent for Kubernetes, you can push a change to your manifest and trigger a Flux sync automatically.
Properly storing, rotating, and managing signing keys can be difficult and typically requires the overhead of managing a separate Key Management System (KMS). GitLab now supports keyless signing through a native integration with the Sigstore Cosign tool which allows for easy, convenient, and secure signing within the GitLab CI/CD pipeline. Signing is done using a very short-lived signing key. The key is generated through a token obtained from the GitLab server using the OIDC identity of the user who ran the pipeline. This token includes unique claims that certify the token was generated by a CI/CD pipeline.
To begin using keyless signing for your build artifacts, container images, and packages, users only need to add a few lines to their CI/CD file as shown in our documentation.
If you’re a power user, using the keyboard to navigate and take action can be frustrating. Now, a new command palette helps you use the keyboard to get more done.
To enable the command palette, open the left sidebar and click Search GitLab (🔍) or use the / key.
Type one of the special characters:
- Create a new object or find a menu item
Code Suggestions now use Google Cloud’s customizable foundation models and open generative AI infrastructure, with generative AI support in Vertex AI.
GitLab Code Suggestions are routed through Google Vertex AI Codey API’s Data Governance and Responsible AI. As of July 22, Code Suggestions inferences against the currently opened file and has a context window of 2,048 tokens and 8,192 character limits. This limit includes content before and after the cursor, the file name, and the extension type. Learn more about Google Vertex AI code-gecko.
The Google Vertex AI Codey APIs directly support: C++, C#, Go, Google SQL, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift, TypeScript. And for infrastructure files, support: Google Cloud CLI, Kubernetes Resource Model (KRM), and Terraform.
We are continuously iterating to improve Code Suggestions. Give it a try and share your feedback with us.
When data scientists create machine learning (ML) models, they often experiment with different parameters, configurations, and feature engineering, so they can improve the performance of the model. The data scientists need to keep track of all of this metadata and the associated artifacts, so they can later replicate the experiment. This work is not trivial, and existing solutions require complex setup.
With machine learning model experiments, data scientists can log parameters, metrics, and artifacts directly into GitLab, giving easy access to their most performant models. This feature is an experiment.
We added a new configuration file to the Value Streams Dashboard for easier customization of the dashboard’s data and appearance. In this file you can define various settings and parameters, such as title, description, and number of panels and filters. The file is schema-driven and managed with version control systems like Git. This enables tracking and maintaining a history of configuration changes, reverting to previous versions if necessary, and collaborating effectively with team members.
The new configuration also includes the option to filter the metrics by labels. You can adjust the metrics comparison panel based on your areas of interest, filter out irrelevant information, and focus on the data that is most relevant to your analysis or decision-making process.
With this release, we’ve extended Advanced Search to include group-level wikis. Users will now be able to find content in these wikis more easily and quickly than before.
7.0.12.Previously, GitLab deployments were linked from the Jira development panel only when a Jira issue was mentioned in either the branch or merge request associated with the deployment. This was often inconvenient for users because it required them to deploy from merge requests, which is not the typical workflow.
With this release, GitLab deployments also scan for Jira issue mentions in the messages of the last 5,000 commits made to the branch after the last successful deployment. The GitLab deployment is associated with all of the mentioned Jira issues.
When invitations are sent to an incorrect email address, they can never be confirmed. Previously, administrators had to manually delete these accounts. Now, administrators can turn on automatic deletion of unconfirmed users after a specified number of days. Similarly, on GitLab.com, unconfirmed accounts will be deleted automatically after the specified number of days.
Feed tokens have been made more secure by only working for the URL they were generated for. This narrows the scope of feeds that can be read if the token was leaked.
With this release, the GitLab for Slack app is available on self-managed instances. On self-managed GitLab, you can create a copy of the GitLab for Slack app from a manifest file and install that copy in your Slack workspace. Each copy is private and not publicly distributable.
To create and configure the app, see GitLab for Slack app administration.
By default, the GitHub importer uses a single access token when importing projects from GitHub to GitLab. An access token for a user account is typically rate limited to 5000 requests per hour. This can significantly reduce the speed of the importer when:
With this release, you can pass a list of access tokens to the GitHub importer API so that the API can rotate through them when rate limited. When using multiple access tokens:
You can now sync OIDC groups to the auditor role in GitLab. This allows automated user lifecycle management facilitated by OIDC to use the auditor role, which was previously unsupported in the role mapping.
Thank you Marin Hannache for your contribution!
The GitLab sign-in and sign-up pages have been improved:
Remember me checkbox with multiple LDAPs.The built-in backup and restore tool adds the ability to skip specific repositories. The Rake task now accepts a list of comma-separated group or project paths to be skipped during the backup or restore by using the new SKIP_REPOSITORIES_PATHS environment variable. This will allow you to skip, for example, stale or archived projects which do not change over time, saving you a) time by speeding up the backup run, and b) space by not including this data in the backup file.
Thanks to Yuri Konotopov for this community contribution!
Geo adds the ability to resync and reverify individual items for all component types managed by the self-service framework. Now you can force a resync or reverification operation on any individual item managed by Geo by using the UI. This can help expedite a resync or reverification operation for failed items, or after changes have been applied to fix sync or verification errors.
For instances which store LFS objects in object storage without proxy download enabled, GitLab now processes LFS requests in bulk. This dramatically improves the performance of downloading a large number of LFS objects.
Previously, due to how LFS objects were fetched, GitLab created many very small requests which checked user permissions and redirected to the object stored externally. This had the potential to cause significant load and a reduction in performance. With this fix, we have reduced load on the primary GitLab instance and provided a faster download experience for our users.
The agentk component of the agent for Kubernetes requires a token to authenticate with GitLab. Previously, you could provide the token as-is, or as a reference to the Kubernetes secret that contains the token. However, you might operate in an environment where the secret is already available in a volume, and prefer to mount that volume instead of creating a separate secret. From GitLab 16.2, the GitLab agent Helm chart ships with this added feature thanks to a community contribution from Thomas Spear.
You can now define custom CI variables, including their values, in the Scan Execution Policies editor. CI variables defined in a policy override the matching variables defined in the projects enforced by the policy. For example, a policy may define a CI Variable SAST_EXCLUDED_ANALYZERS to brakeman. When the scanner is enforced in a project, the scanner will run with the variable set to brakeman regardless of any variables defined in the project’s CI configuration. For each scan type, you can define values for default variables, also create custom key-value pairs for custom CI variables. This makes customizing a scan execution policy quicker and easier.
In previous GitLab versions, security policies were not enforced on projects without a .gitlab-ci.yml file, or where AutoDevOps was disabled. In GitLab 16.2, security policies implicity enable CI/CD pipelines on projects that do not contain a .gitlab-ci.yml file. This is another step in ensuring compliance of security policies and allow you to enforce secret detection, static analysis, or any other jobs where builds are not required.
Scan execution and scan result policies will allow you to scope enforcement to branches that are “Default” branches or “Protected branches” across the many projects a policy is enforcing. Rather than requiring policies to specify branch names explicitly, policies can be enforced more broadly and ensure branches with atypical names are not excluded from compliance.
Branch rules can be configured across our various security policy rule types by using the branch_type field:
You can now select Google Cloud Logging as a destination for audit event streams.
Previously, you had to use the headers to try to build a request that Google Cloud Logging would accept. This method was prone to errors and could be difficult to troubleshoot.
Now, you can select Google Cloud Logging as the destination for the stream and provide your project ID, client email, log ID, and private key to allow for a more seamless integration.
You can now export a report of compliance frameworks and their associated projects to a CSV file.
With the addition of the compliance frameworks report at the group level, you were able to see and manage which projects your compliance frameworks applied to.
With the new export, you can keep a copy of that file for reference. You might keep the file as a single source of truth for the ideal state of your project and compliance framework relationships. Or you might send the file people in your organization who may not work in GitLab, but have an interest in seeing which projects are tagged with which frameworks.
When reviewing a list of dependencies, it is important to have an overall view.
Managing dependencies at the project level is problematic for large organizations that want to audit their dependencies across all their projects.
With this release, you can see all dependencies at the project or group level, including subgroups. This feature is off by default behind feature flag group_level_dependencies.
In previous versions of GitLab, when a default branch was fully protected, only project maintainers and owners could push an initial commit to a default branch.
This caused problems for developers who created a new project, but couldn’t push an initial commit to it because only the default branch existed.
With the Fully protected after initial push setting, developers can push the initial commit to the default branch of a repository, but cannot push any commits to the default branch afterward. Similar to when a branch is fully protected, project maintainers can always push to the default branch but no one can force push.
Before GitLab 16.1, only audit events from top-level groups could be streamed to an external destination.
Now, instance administrators can add a streaming destination for audit events produced at the instance level.
In previous version of GitLab, you had to use the GraphQL API to add audit event type filters to your audit event streams.
Now, you can use the filter dropdown in the GitLab UI to see all the available audit event types, grouped by the area of GitLab to which they are relevant, and search for the exact types you want to send in a stream.
This significantly reduces the time needed to add filtering to audit event streams because you no longer have to pull the entire list using the API and search through the list manually.
When you suggest changes in a merge request, you can now edit your suggestions more quickly. In a comment, switch to the rich text editor and use the UI to move up and down the lines of text. With this change, you can view your suggestions exactly as they will appear when the comment is posted.
The rich text editor is a new way of editing in GitLab. It’s available in merge requests, but also available alongside the plain text editor in issues and epics.
We plan to have the rich text editor available in more areas of GitLab soon and we are actively working on that. You can follow our progress here.
Have you been thinking about moving your PyPI repository to GitLab, but haven’t been able to invest the time to migrate? In this release, GitLab is launching the first version of a PyPI package importer.
You can now use the Packages Importer tool to import packages from any PyPI-compliant registry, like Artifactory.
You can now express your thoughts more creatively by adding emoji reactions to comments in Design Management. This feature adds a touch of fun and ease to collaboration, fostering better communication and enabling teams to provide quick feedback in a more expressive way.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports.
During the 16.2 release milestone, our changes focused on the Semgrep-based analyzer and the GitLab-maintained rules it uses for scanning. We released the following changes:
.gitignore exclusion. Thanks to @SimonGurney for this community contribution..semgrepignore files. Thanks to @hmrc.colinameigh for this community contribution.@tyage for this community contribution.-1 suffix added to the Semgrep rule IDs for JavaScript rules. This was added in GitLab 16.0 as a side-effect of an unrelated change, but interfered with customers’ existing semgrepignore comments.See the semgrep CHANGELOG and sast-rules CHANGELOG for further details.
We’re tracking further improvements to GitLab-managed rulesets in epic 10907.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
We regularly release updates to the GitLab Secret Detection analyzer. During the GitLab 16.2 milestone, we:
@nathanwfish for this community contribution.keywords optimization.See the CHANGELOG for further details.
If you use the GitLab-managed Secret Detection template (Secret-Detection.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see the most recent Secret Detection update.
In addition to NuGet v1 lock files, GitLab Dependency and License Scanning both now support analyzing dependencies defined in NuGet v2 lock files.
GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves. We’ve released two improvements in GitLab 16.2:
We’re tracking further improvements, including expansion to more languages, better handling of more language constructs, and improved tracking for Python and Ruby, in epic 5144.
These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.
when: never on conditional includesinclude is one of the most popular keywords to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.
In this release, we are expanding the power of the keyword so you can use when: never when using rules with include. Now, you can decide when external CI/CD configuration will be excluded when a specific rule is satisfied. This will help you write a standardized pipeline with better ability to dynamically modify itself based on the conditions you choose.
We have now made our medium GitLab SaaS runner on Linux with 4 vCPUs and 16 GB RAM available to all tiers.
Previously users on the Free tier were only able to use our small Linux runner, sometimes causing longer CI/CD execution times. We are excited to see our Free users accelerate their pipeline speeds.
We’re also releasing GitLab Runner 16.2 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On June 22, 2023, GitLab 16.1 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Gerardo has been consistently iterating over multiple releases to deliver the REST API endpoints for job token scope. Iteration is one of our core values at GitLab, and Gerardo has exemplified that with his multiple contributions to deliver the feature.
Due to the change in default CI_JOB_TOKEN behavior,
users who automate creation of projects cannot also automate adding the projects allowed to use
a CI_JOB_TOKEN with the project. This REST API endpoint enables our customers to automate this
process again and drive increased adoption of a more secure CI_JOB_TOKEN workflow.
Thanks to Gerardo and the rest of the crew from Siemens!
Yuri picked up an issue that was logged 6 years ago, took a bias for action (one of our GitLab values) and contributed a fix.
This was a popular feature that a number of customers were interested in. This enhancement allows the system admin to skip specific projects during backup and restore, based on a comma-separated list of group or project paths. With this feature, system admins can skip over stale or archived projects during their backup run, save storage space and speed up the backup. They can also exclude specific projects when restoring from backup using the same option.
Thanks to Yuri for his valuable contribution!
GitLab 16.1 features an all-new navigation experience! We’ve defaulted this experience to on for all users. To get started, go to your avatar in the top right of the UI and turn on the New navigation toggle.
The new navigation was designed to solve three key areas of feedback: navigating GitLab can be overwhelming, it can be hard to pick up where you left off, and you can’t customize the navigation.
The new navigation includes a streamlined and improved left sidebar, where you can:
We are proud of the new navigation and can’t wait to see what you think. Review a list of what’s changed and read our blog posts about the navigation vision and design.
Please try the new navigation and let us know about your experience in this issue. We are already addressing the feedback and will eventually remove the toggle.
How do you check the status of the applications running in your clusters? The pipeline status and environment pages provide insights about the latest deployment runs. However, previous versions of GitLab lacked insights about the state of your deployments. In GitLab 16.1, you can see an overview of the primary resources in your Kubernetes deployments.
This feature works with every connected Kubernetes cluster. It doesn’t matter if you deploy your workloads with the CI/CD integration or GitOps. To further improve the feature for Flux users, support for showing the synchronization status of an environment is proposed in issue 391581.
There are many use cases for which a non-human user might need to authenticate. Previously, depending on the desired scope, users could use personal, project, or group access tokens to meet this need. These tokens were not ideal, due to still being either tied to a human (for personal access tokens), or an unnecessarily privileged role (for group and project access tokens).
Service accounts are not tied to a human user, and are more granular in scope. Service account creation and management is API-only. Support for a UI option is proposed in issue 9965.
GitLab Dedicated is a fully managed, single-tenant SaaS deployment of our comprehensive DevSecOps platform designed to address the needs of customers with stringent compliance requirements.
Customers in highly-regulated industries are unable to adopt multi-tenant SaaS offerings due to strict compliance requirements like data isolation. With GitLab Dedicated, organizations can access all of the benefits of the DevSecOps platform – including faster releases, better security, and more productive developers – while satisfying compliance requirements such as data residency, isolation, and private networking.
Learn more about GitLab Dedicated today.
Previously, if you wanted to view or manage job artifacts, you had to go to each job’s detail page, or use the API. Now, you can view and manage job artifacts through the Artifacts page accessed at Build > Artifacts.
Users with at least the Maintainer role can use this new interface to delete artifacts too. You can delete individual artifacts, or bulk delete up to 100 artifacts at a time through either manual selection or checking the Select all option at the top of the page.
Please use the survey at the top of the Artifacts page to share any feedback you have about this new functionality. To view additional UI features under consideration, you can check out the Build Artifacts page enhancements epic.
CI/CD variables are a key part of all pipelines and can be defined in multiple places, including in the project and group settings. To prepare for making bigger improvements that will help users intuitively navigate between variables at different hierarchy, we are starting out with improving the usability and layout of the variable list.
In GitLab 16.1, you will see the first iteration of these improvements. We have merged the “Type” and “Options” columns into a new Attributes column, which better represents these related attributes. We appreciate your feedback on how we can continue to improve the CI/CD variable experience, you are welcome to comment in our variables improvement epic.
busybox Docker image with gitlab-base Docker image to share layers with other GitLab
Docker images. This implementation treats gitlab-base as a helper image (like kubectl and certificates),
with optional local overrides.Bookworm that released on June 10, 2023.Domain verification serves multiple purposes across GitLab. Previously, in order to verify a domain, you had to complete the GitLab Pages wizard, even if you were verifying a domain for a purpose outside of GitLab Pages.
Now, domain verification lives at the group level, and has been streamlined. This makes it easier to verify your domains.
The ability to view the vulnerability report is now split into a separate permission, enabling GitLab administrators and group owners to create a custom role with this permission. Previously, viewing the vulnerability report was limited to the Developer role and above. Now, any user can view the vulnerability report, as long as they are assigned a custom role that has the permission.
If you forget your GitLab password, you can now reset it by email with any verified email address. Previously, only the primary email address was used for reset requests. This made it difficult to complete the password reset process if the primary email inbox was inaccessible.
The users API now returns the SCIM identities for a user. Previously, this information was included in the UI but not the API.
Shibboleth OmniAuth support has been re-introduced to GitLab. It was previously removed in GitLab 15.9 due to lack of upstream support. Thanks to a generous community contribution by lukaskoenen, who took on upstream support, omniauth-shibboleth-redux is now supported in self-managed GitLab.
GitLab administrators can use Admin Mode to work as a non-administrator user, and turn on administrator access when needed. Previously, an administrator’s personal access token (PAT) always had permissions to perform API actions as an administrator. Now, when adding a PAT, an administrator can decide if that PAT has administrator access to perform API actions or not, by selecting the Admin Mode scope. An administrator must enable Admin Mode for the instance to use this feature.
Thank you Jonas Wälter, Diego Louzán, and Andreas Deicha for contributing!
Administrators can prevent users from deleting their account with a new user restrictions configuration setting. If this setting is enabled, users will no longer be able to delete their accounts, preserving auditable account information.
last_used value updated more frequentlyThe last_used value for personal access tokens (PAT) was previously updated every 24 hours. It is now updated every 10 minutes. This increases visibility of PAT usage and, in the case of PAT compromise, reduces risk because it takes less time before malicious activity is noticed.
Thank you Jacob Torrey for your contribution!
When a GitHub project finished importing, GitLab showed a simple summary of imported entities. However, GitLab didn’t show exactly which GitHub entities failed to import nor the errors that caused the import failures. This made it difficult to decide if import results were satisfactory or not.
In this release, we have extended the import summary to include a list of GitHub entities that weren’t imported and, if possible, provide a direct link to these entities on GitHub. GitLab now also shows an error for each failure. This helps you understand how well the import worked and helps you troubleshoot problems.
When a requester replies to a Service Desk email, it is useful to the Service Desk agent to know who made the comment. But because the requester can be an external user with no GitLab account or access to the GitLab project, these comments were previously attributed to the GitLab Support Bot. From now on, email replies from requesters will be attributed to the external users, making it more clear who made the comments in the GitLab issue.
For Service Desk requesters, it can be helpful to access the Service Desk issue directly rather than interact with the Service Desk request only via email. We are introducing a new placeholder %{ISSUE_URL}, that you can use in your email templates (for example, the “thank you” email) to link requesters directly to the Service Desk issue.
The built-in backup and restore tool adds the ability to skip specific repositories. The Rake task now accepts a list of comma-separated group or project paths to be skipped during the backup or restore by using the new SKIP_REPOSITORIES_PATHS environment variable. This will allow you to skip, for example, stale or archived projects which do not change over time, saving you a) time by speeding up the backup run, and b) space by not including this data in the backup file.
Thanks to Yuri Konotopov for this community contribution!
Geo adds filtering by replication status to all components managed by the self-service framework. Now you can filter items in the replication details views by “In progress”, “Failed”, and “Synced” status making it easier and faster to locate data that is failing to synchronize.
When you add a design to an issue, a design Git repository is created or updated, and an LFS object and an upload (for the thumbnails) are created. Geo already verifies LFS objects and uploads, and now it also verifies the design repositories as well. Now that all underlying data of Design Management is verified, your design data is ensured to not be corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects you against data loss.
Merge requests now support commenting on an entire file, because not all merge request feedback is line-specific. If a file is deleted, you might want more information about why. You might also want to provide feedback about a filename, or general comments about structure.
Changelogs generate comprehensive lists of changes based on commits to a project. They can be challenging to automate or view, and require interacting with the GitLab API.
With the release of GitLab CLI v1.30.0 you can now generate changelogs for projects directly from your shell. The glab changelog generate command makes it easier to review, automate, and publish changelogs.
Thanks Michael Mead for your contribution!
Security and compliance policies allow organizations to enforce checks and balances across multiple projects to align with their security and governance programs. It’s critical for our customers to ensure changes that impact policies do not result in the guardrails coming down. With this update, invalid rules will “fail closed”, blocking MRs until invalid rules in any scan result policies are addressed.
You can use your project’s Package Registry to publish and install npm packages. You simply authenticate using an access token (personal, job, deploy, or project) and start publishing packages to your GitLab project.
This works great if you have a small number of projects. Unfortunately, if you have multiple projects, you might quickly find yourself adding dozens or even hundreds of different sources. It is common for teams in large organizations to publish packages to their project’s Package Registry alongside the source code and pipelines. Simultaneously, they need to be able to easily install dependencies from other projects within the groups and subgroups in their organization.
To make sharing packages easier between projects, you can now install packages from your group so you don’t have to remember which package lives in which project. Using an authentication token of your choice, you can install any of the group npm packages after you add your group as a source for npm packages.
Currently the Design uploads have no metadata to explain their purpose, or why they are being uploaded. We’ve added a text box as a description so you can help users understand the image better.
You can now configure the static file directory for GitLab Pages to any name (by default public).
This makes it easier to use Pages with popular static site frameworks such as Next.js, Astro, or Eleventy,
without needing to change the output folder in their configuration.
GitLab Code Quality supports integrating tools you already run and also offers a CI/CD template that runs the CodeClimate scanning system. We published the following updates to the CodeClimate-based analyzer during the 16.1 release milestone:
golangci-lint.bundler-audit plugin.@tsjnsn for this community contribution. Updates to include this variable in the CI/CD template are tracked in an issue.See the CHANGELOG for further details.
If you include the GitLab-managed Code Quality template (Code-Quality.gitlab-ci.yml), you automatically receive these updates.
For Code Quality changes in previous releases, see the most recent update.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.1 release milestone:
SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable. This allows you to improve performance by reducing the scan’s precision and its ability to detect vulnerabilities. See the CHANGELOG for further details.If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
We’ve integrated Secret Detection with Google Cloud to better protect customers who use GitLab to develop applications on Google Cloud. Now, if an organization leaks a Google Cloud credential to a public project on GitLab.com, GitLab can automatically protect the organization by working with Google Cloud to protect the account.
Secret Detection searches for three types of secrets issued by Google Cloud:
Publicly leaked secrets are sent to Google Cloud after they’re discovered. Google Cloud verifies the leaks, then works to protect customer accounts against abuse.
This integration is on by default for projects that have enabled Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently only available in Ultimate projects.
See the blog post about this integration for further details.
We’ve updated the GitLab SAST rules to:
These improvements are part of a collaboration between the GitLab Static Analysis and Vulnerability Research teams to improve the default Static Analysis rulesets. We would welcome any feedback on the default rules for SAST, Secret Detection, and IaC Scanning in epic 8170.
For more details on the changes to GitLab SAST rules, see the CHANGELOG.
As of GitLab 16.1, the sast-rules project is the single source of all GitLab-managed default rules used in the Semgrep-based SAST analyzer.
You can now set a CI/CD variable to share ruleset customizations for SAST, IaC Scanning, or Secret Detection across more than one project.
Sharing a ruleset can help you:
Further improvements in this area are discussed in an issue.
needs in rulesThe needs: keyword defines a dependency relationship between jobs, which you can use to set jobs to run out of stage order. In this release we’ve added the ability to define this relationship for specific rules conditions. When a condition matches a rule, the job’s needs configuration is completely replaced with the needs in the rule. This can help speed up a pipeline based on your defined conditions, when a job can start earlier than normal. You can also use this to force a job to wait for an earlier one to complete before starting, you now have more flexible needs options!
One of GitLab’s most used features is CI/CD. In 16.1, we focused on improving the usability and experience of CI/CD pipeline and job list views, as well as the pipeline details page. It’s now easier to find the information you are looking for! If you have any comments about the changes, we’d love to hear from you in our feedback issue.
After recently upsizing our GitLab.com SaaS runners on Linux in vCPU and RAM, we have now also increased the storage for medium and large machine types.
You can now seamlessly build, test, and deploy larger applications that require a secure, on-demand GitLab Runner Linux environment fully integrated with GitLab CI/CD.
Starting in GitLab 16.0, the default CI/CD job token (CI_JOB_TOKEN) scope changed for all new projects. This increased the security of new projects, but added an extra step for users who used automation to create projects. The automation sometimes has to configure the job token scope as well, which could only be done with GraphQL (or manually in the UI), not the REST API.
To make this setting configurable through the REST API as well, Gerardo Navarro added a new endpoint to control the job token scope in 16.1. It is available to users with a Maintainer or higher role in the project. Thank you for this great contribution Gerardo!
The new runner creation method enables you to re-use a runner configuration for scenarios where you may need to register multiple runners with the same capabilities. Runners registered with the same authentication token share a configuration and are grouped in the new detailed view.
We’re also releasing GitLab Runner 16.1 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG.
On May 22, 2023, GitLab 16.0 was released with the following features.
In addition, we want to thank all of our contributors, including this month’s notable contributor.
Jimmy improved the merge request security widget by correcting which merge base is used for comparing branches on completed pipelines in the merge request. Previously, the merge request security widget was comparing the most recent security scan of a completed pipeline on the main branch of the repository. For the vulnerability findings in the merge request security widget to be accurate, we needed to adjust the logic and compare the feature branch to the main branch at the time the feature was branched from main. Without this change users might see misleading results. This was already an issue on our roadmap, and Jimmy contributed and accelerated this improvement not only for them, but for all GitLab users.
Jimmy stated:
I’ve contributed to a variety of open source projects, but have never experienced such a helpful review process.
Thank you Jimmy for helping us iterate on the logic for vulnerability findings and improve the security features in GitLab!
This new dashboard provides strategic insights into metrics that help decision-makers identify trends and patterns to optimize software delivery. The first iteration of the GitLab Value Streams Dashboard is focused on enabling teams to continuously improve software delivery workflows by benchmarking value stream life cycle (value stream analytics, DORA4), and vulnerabilities metrics.
Organizations can use the Value Streams Dashboard to track and compare these metrics over a period of time, identify downward trends early, understand security exposure, and drill down into individual projects or metrics to take actions for improvements.
This comprehensive view built as a single application with a unified data store allows all stakeholders, from executives to individual contributors, to have visibility into the software development life cycle, without needing to buy or maintain a third-party tool.
You asked, we listened! In our efforts to be best-in-class for CI/CD build speeds, we’re doubling the vCPU & RAM for all GitLab SaaS runners on Linux, with no increase in the cost factor.
We’re excited to see pipelines run faster and boost productivity.
We are aiming to bring the best practices of DevSecOps to data sciences by providing more powerful compute hardware within GitLab runner. Previously, data scientists may have had workloads that were compute-intensive and as a result, jobs may not have been as quickly executed in GitLab.
Now, with GPU-enabled SaaS runners on Linux, these workloads can be seamlessly supported using GitLab.com.
So why wait? Try out the new runner today and let us know what you think in this issue. We can’t wait to hear your feedback!
Mobile DevOps teams can now run their entire CI/CD workflows on Apple silicon (M1) GitLab SaaS runners on macOS to seamlessly create, test, and deploy applications for the Apple ecosystem.
With up to three times the performance of hosted x86-64 macOS Runners, you will increase your development team’s velocity in building and deploying applications that require macOS in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.
When you’re commenting in issues, epics, or merge requests you might repeat yourself and need to write the same comment over and over. Maybe you always need to ask for more information about a bug report. Maybe you’re applying labels via a quick action as part of a triage process. Or maybe you just like to finish all your code reviews with a funny gif or appropriate emoji. 🎉
Comment templates enable you to create saved responses that you can apply in comment boxes around GitLab to speed up your workflow. To create a comment template, go to User settings > Comment templates and then fill out your template. After it’s saved, select the Insert comment template icon on any text area, and your saved response will be applied.
This is a great way to standardize your replies and save you time!
Managing your fork just got easier. When your fork is behind, select Update fork in the GitLab UI to catch it up with upstream changes. When your fork is ahead, select Create merge request to contribute your change back to the upstream project. Both operations previously required you to use the command line.
See how many commits your fork is ahead (or behind) on your project’s main page and at Repository > Files. If merge conflicts exist, the UI gives guidance on how to resolve them using Git from the command line.
Do you need to mirror a busy repository with many branches, but you only need a few of them? Limit the number of branches you mirror by creating a regular expression that matches only the branches you need.
Previously, mirrors required you to mirror an entire repository, or all protected branches. This new flexibility can decrease the amount of data your mirrors push or pull, and keep sensitive branches out of public mirrors.
Since its introduction, we’ve been iterating on the usability, performance, and stability of the Web IDE, which has enabled us to build features like remote development workspaces and code suggestions on a powerful foundation.
We have received overwhelmingly positive feedback on the Web IDE Beta and starting in GitLab 16.0, we are making it the default multi-file code editor across GitLab.
Stop spending hours, or even days, troubleshooting your local development environment and interpreting inscrutable package installation errors. Now you can define a consistent, stable, and secure development environment in code and use it to create on-demand; all inside Workspaces.
Workspaces serve as personal, ephemeral development environments in the cloud. By eliminating the need for a local development environment, you can focus more on your code and less on your dependencies. Accelerate the process of onboarding to a new project and get up and running in minutes instead of days.
After the GitLab Agent for Kubernetes is configured and the dependencies are installed in your self-hosted cluster or cloud platform of choice, you can define your development environment in a .devfile.yaml file and store it in a public project. Then, you and any other developers with access to the agent can create a workspace based on the .devfile.yaml file and edit directly in the embedded Web IDE. You’ll have full terminal access to the container, allowing you to work more efficiently. When you’re done, or if something goes wrong, you can shut down the workspace and start a fresh, new workspace for your next development task.
This short video walks you through the lifecycle of a workspace in the current Beta. Learn more about workspaces in the documentation and let us know what you think in the feedback issue.
As security shifts left, remediating security findings without guidance can be challenging. Developers need actionable advice so they can resolve vulnerabilities and continue building features. Contextual training that is relevant to the specific vulnerability detected was released in GitLab 14.9.
In this release, we are adding an integration with SecureFlag based upon the CWE of the vulnerability. SecureFlag’s training solution is unique in that the labs involve remediating the vulnerability in a live environment, which can be transferred to a real environment.
Previously, to rotate tokens, the token owner had to manually create a new token and replace the existing token.
Now, token owners can use a :rotate API endpoint to programatically rotate personal, group, and project access tokens.
GitLab is evolving into an AI‑powered DevSecOps platform. Over the past month, we’ve introduced 10 new experiments to improve efficiency and productivity across various GitLab features, all leveraging AI.
These AI-powered workflows boost efficiency and reduce cycle times in every phase of the software development lifecycle.
Learn more about AI-powered workflows
Code Suggestions is now available on GitLab.com for all users for free while the feature is in Beta. Teams can boost efficiency with the help of generative AI that suggests code while you’re developing.
We’ve extended language support from our initial six languages to now include 13 languages: C/C++, C#, Go, Java, JavaScript, Python, PHP, Ruby, Rust, Scala, Kotlin, and TypeScript.
We are making improvements to the Code Suggestions underlying AI model weekly to improve the quality of suggestions. Please remember that AI is non-deterministic, so you may not get the same suggestion week to week.
Read more about these improvements and what’s next.
GitLab Error Tracking, which allows developers to discover and view errors generated by their application, is now generally available on GitLab.com! GitLab error tracking helps to increase efficiency and awareness by surfacing error information directly in the same interface as the code is developed, built, deployed, and released.
In this release, we are supporting both the GitLab integrated error tracking and the Sentry-based backends.
To improve the visibility into the complete workstream, we are adding to the project-level Value Stream Analytics (VSA) the Overview stage and the option to create custom value streams.
Until now, these features were only available at the group-level VSA only.
Unauthenticated users of the Projects List API will be subject to rate limitations moving forward.
On GitLab.com, the limit is set to 400 requests per 10 minutes per unique IP address.
Users of self-managed GitLab instances have the same rate limitation by default, but administrators can change the rate limits as they see fit. We encourage users who need to make more than 400 requests per 10 minutes to the Projects List API to sign up for a GitLab account.
Starting with 16.0, self-managed installations of GitLab will have two database connections by default, instead of one. This change makes self-managed versions of GitLab behave similarly to GitLab.com, and is a step towards enabling a separate database for CI features for self-managed versions of GitLab.
This change applies to installation methods with Omnibus GitLab, GitLab Helm chart, GitLab Operator, GitLab Docker images, and installation from source.
We have received feedback from users who wanted to prevent getting unwanted followers of their user profile. We listened to your concerns, so now, in your user profile settings under Preferences, you can disable following.
When you disable this feature, no one can follow you, and you cannot follow anyone. All existing following and follower relationships are removed, and the count is set to zero.
To prevent accidental deletion of projects and groups, starting in GitLab 16.0, the delayed deletion feature will be turned on by default for all GitLab Ultimate and Premium customers.
Self-managed users still have the option to define a deletion delay period of between 1 and 90 days, and SaaS users have a non-adjustable default retention period of 7 days.
Users of Ultimate and Premium groups can still delete a group or project immediately from the group or project settings via a two-step deletion process.
We believe that this change will contribute to a safer deletion process and will be beneficial in preventing accidental deletions. We’d love your feedback in issue #396996.
global.registry.* configuration for simplification because the values are present in both. You can keep the old behavior with an override.GitLab Free customers with a self-managed instance running GitLab Enterprise Edition can now access five more paid features under the Registration Features program:
To get access to these features, register with GitLab and send us activity data through Service Ping.
In GitLab 15.10, we started mapping GitHub repository collaborators as GitLab project members during GitHub project imports. We received feedback that this led to confusion and that some GitHub collaborators were unexpectedly added and consumed seats.
In GitLab 16.0, we’ve iterated and added GitHub repository collaborators to the list of additional items to import. This gives users the option to avoid importing these users and to understand the possible implications of importing them.
This option is selected by default. Leaving it selected might result in new users using a seat in the group or namespace, and being granted permissions as high as project owner. Only direct collaborators are imported. Outside collaborators are never imported.
If you own or collaborate on a lot of repositories in GitHub, you might have trouble finding those that you want to import to GitLab using the current filtering option.
To make finding the right repositories easier, we have added additional filters. You can now list subsets of the repositories you can import using three tabs:
On the Organization tab, you can further narrow down your search and choose a specific organization and list only repositories belonging to that organization.
When a user raises an access request for a group or project, the request appears in the To-Do List of the group or project owner. For groups and projects that have multiple owners, the request appears in each owner’s To-Do List.
With this new functionality, to-do items that have already been completed by another owner are marked Done in the others’ To-Do Lists.
GitLab 16.0 features an all-new navigation experience! To get started, go to your avatar in the top right of the UI and turn on the New navigation toggle. The left sidebar changes to a new and improved design, based on user feedback we’ve received over the last year.
Please let us know about your experience in this issue. Based on the feedback, we will be progressively enabling the new navigation across our user base, with the final step being removal of the old navigation.
Administrators can remove the “Remember Me” option for users when signing in so that sessions cannot be extended and the user is forced to re-authenticate. Limiting the duration of a session may improve instance security.
Previously, you could only authenticate the Jira issue integration with a Jira username and password.
Now you can use a Jira personal access token to authenticate if you are using Jira Data Center and Jira Server with Jira 8.14 and later. A Jira personal access token is a safer alternative to a username and password.
It is useful for a Service Desk requester to see their original request in the automated thank you email replies.
In this release, we add an %{ISSUE_DESCRIPTION} placeholder so that Service Desk administrators can include the original request in the thank you email.
When working on merge requests, it’s important to make sure that what you’re seeing is the latest information for approvals, pipelines or other information that might impact your ability to get the changes merged. Historically, this has meant refreshing the merge request or waiting for polling updates to come through.
We’ve improved the experience of both the merge button widget and approval widget inside of the merge request, so that they now update in real-time in the merge request. This is a great improvement to improve the speed at which you can deliver changes, and the confidence at which you can move a merge request forward knowing you’re seeing the latest information.
We’re looking at more areas for real-time improvements in merge requests, so follow along for updates.
When selecting one or more vulnerabilities in the vulnerability report, it’s possible to change their status in bulk.
With this release, you can now select a dismissal reason when choosing the dismiss status, and add a comment when changing a vulnerability’s status."
In GitLab 15.11, we added bulk adding and removing of compliance frameworks to the compliance frameworks report.
Now in GitLab 16.0, you can also add and remove compliance frameworks from projects directly from the report table row.
Before GitLab 16.0, you had to create and edit frameworks in the group’s settings.
Now in GitLab 16.0, you can create or edit your compliance frameworks in the compliance framework report as well. This simplifies the framework creation workflow and reduces the need to switch contexts while managing your frameworks.
Prior to GitLab 16.0, the compliance violations report showed all violations on all branches.
Now you can now filter violations using the new Search target branch field, allowing you to focus on the branches that you are most concerned with.
With role-based approval actions, you can configure scan result policies to require approval from GitLab-supported roles, including Owners, Maintainers, and Developers.
This gives you additional flexibility over requiring individual approvers or defined groups of users, making it easier to enforce policies based on roles you already leverage in GitLab, at scale, especially across large organizations.
Previously, GitLab’s DAST analyzers did not support callback attacks while performing active checks. This meant that Out-of-band Application Security Testing (OAST) needed to be configured separately from your DAST scan.
Now, you can run OAST by extending the browser-based DAST analyzer configuration to enable callback attacks.
In this release we are introducing the BAS.latest.GitLab-ci.yml template. The Breach and Attack Simulation CI/CD template features job configuration for the browser-based DAST analyzer and enables container-to-container networking to add extended DAST scans against service containers to your CI/CD pipeline.
We’re continuously iterating to develop new Breach and Attack Simulation features. We’d love to hear your feedback on the addition of callback attacks to browser-based DAST.
Have you been thinking about moving your Maven or Gradle repository to GitLab, but haven’t been able to invest the time to plan the migration? GitLab is proud to announce the MVC launch of a Maven/Gradle package importer.
You can now use the Packages Importer tool to import packages from any Maven/Gradle compliant registry, like Artifactory.
To use the tool, simply create a config.yml file that contains the details of the packages you want to import into GitLab. Then add the importer to a .gitlab-ci.yml pipeline configuration file, and the importer does the rest. It runs in the pipeline, dynamically generating a child pipeline with jobs that import all the packages into your GitLab package registry.
The GitLab Package Registry now supports downloading Maven packages using the Scala build tool (sbt). Previously, Scala users had no way to download Maven packages from the registry because basic authentication was not supported. As a result, Scala users were either blocked from using the registry or had to use Maven (mvn) or Gradle as an alternative.
By adding support for Scala, we hope to help you use the Package Registry with your more data intensive projects.
Please note that publishing artifacts using sbt is not yet supported, but you can follow issue 408479 if you are interested in adding support for publishing.
We know that GitLab To-Do List is a widely adopted feature, but it was not available on tasks, objectives, and key results.
In this release, we’re introducing the ability to toggle a to-do item on or off from a work item record.
In previous versions of GitLab, cookies of different GitLab Pages sites under the same top-level group were visible for other projects under the same top-level because of the GitLab Pages default URL format.
Now, you can secure your sites by assigning a unique subdomain to each GitLab Pages project.
You can now contribute to tasks, objectives and key results with the addition of emoji reactions for work items.
Before this release, you could only add reactions on issues, merge requests, snippets, and epics.
With this additional quick action, you can now convert key results to objectives.
Until now, you could specify only a fixed number of colors for your labels.
This release introduces a color picker to label management, allowing you to select any range of colors for your labels.
If you’re a user of tasks or OKRs you’ve likely wished more than once that we could reorder the child records within the widget!
With this work, users will now be able to reorder child records within work item widgets allowing them to indicate relative priority or signal what’s up next.
Value Stream Analytics has been extended with two new stage events: issue first assigned and merge request first assigned. These events can be useful for measuring the time it takes for an item to be first assigned to a user.
To implement this feature, GitLab started storing the history of assignment events in GitLab 16.0. This means that issue and MR assignment events prior to GitLab 16.0 are not available.
GitLab now shows you a message on the Environments page when a deploy freeze is in effect. This helps ensure your team is aware of when freezes occur, and when deployments are not allowed.
GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.0 release milestone:
@artem-fedorov for this community contribution.PyYAML.load rule. Thanks to @stevep-arm for this community contribution.--neverignore flag to disregard “ignore” directives in comments. See the CHANGELOG for further details.Also, as previously announced, we increased the major version number of each analyzer as part of GitLab 16.0.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
We regularly release updates to the GitLab Secret Detection analyzer. During the GitLab 16.0 milestone, we:
5, as previously announced.See the CHANGELOG for further details.
If you use the GitLab-managed Secret Detection template (Secret-Detection.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.
For previous changes, see last month’s updates.
We have optimized the way that the browser-based DAST analyzer performs its scans. These improvements have significantly decreased the amount of time that it takes to run a DAST scan with the browser-based analyzer. The following improvements have been made:
DAST_BROWSER_LOG="stat:debug".With these improvements, we have seen browser-based DAST scan times reduced by 50%-80%, depending on the complexity and size of the application being scanned. While this percentage decrease may not be seen in all scans, your browser-based DAST scans should now take significantly less time to complete.
GitLab Static Application Security Testing (SAST) now offers Semgrep-based scanning for Scala code. This work builds on our previous introduction of Semgrep-based Java scanning in GitLab 14.10. As with the other languages we have transitioned to Semgrep-based scanning, Scala scanning coverage uses GitLab-managed detection rules to detect a variety of security issues.
The new Semgrep-based scanning runs significantly faster than the existing analyzer based on SpotBugs. It also doesn’t need to compile your code before scanning, so it’s simpler to use.
GitLab’s Static Analysis and Vulnerability Research teams worked together to translate rules to the Semgrep format, preserving most existing rules. We also updated, refined, and tested the rules as we converted them.
If you use the GitLab-managed SAST template (SAST.gitlab-ci.yml), both Semgrep-based and SpotBugs-based analyzers now run whenever Scala code is found.
In GitLab Ultimate, the Security Dashboard combines findings from the two analyzers, so you won’t see duplicate vulnerability reports.
In a future release, we’ll change the GitLab-managed SAST template (SAST.gitlab-ci.yml) to only run the Semgrep-based analyzer for Scala code.
The SpotBugs-based analyzer will still scan code for other languages, including Groovy and Kotlin.
You can disable SpotBugs early if you prefer to use only Semgrep-based scanning.
If you have any questions, feedback, or issues with the new Semgrep-based Scala scanning, please file an issue, we’ll be glad to help.
In this new workflow, adding a new runner to a GitLab instance requires authorized users to create a runner in the GitLab UI and include essential configuration metadata. With this method, the runner is now easily traceable to the user, which will help administrators troubleshoot build issues or respond to security incidents.
Previously, a trigger job configured with strategy: depends mirrored the job status of the downstream pipeline. If the downstream pipeline was in the running status, the trigger job was also marked as running. Unfortunately, if the downstream job did not comnplete and had a status canceled, the trigger job’s status was inaccurately failed.
In this release, we have updated trigger jobs with strategy: depend to reflect the downstream’s pipelines’s statis accurately. When a downstream pipeline is cancelled, the trigger also shows canceled.
This change may have an impact on your existing pipelines, especially if you have jobs that rely on the trigger job’s status being marked as failed. We recommend reviewing your pipeline configurations and making any necessary adjustments to accommodate this change in behavior.
In this release we are excited to announce the availability of CI/CD components, as an experimental feature. A CI/CD component is a reusable single-purpose building block that can be used to compose a part of a project’s CI/CD configuration, or even an entire pipeline.
When combined with the inputs keyword, a CI/CD component can be made much more flexible. You can configure the component to your exact needs by inputting values which can be used for job names, variables, credentials, and so on.
Users can now use the new REST API endpoint, POST /user/runners, to automate the creation of runners associated with a user. When a runner is created, an authentication token is generated. This new endpoint supports the Next GitLab Runner Token Architecture workflow.
Using a cache is a great way to speed up your pipelines by reusing dependencies that were already fetched in a previous job or pipeline. But when there is no cache yet, the benefits of caching are lost because the job has to start from scratch, fetching every dependency.
We previously introduced a single fallback cache to use when no cache is found, that you can define globally. This was useful for projects that used a similar cache for all jobs. Now in 16.0 we’ve improved that feature with per-cache fallback keys. You can define up to 5 fallback keys for every job’s cache, greatly reducing the risk that a job runs without a useful cache. If you have a wide variety of caches, you can now use an appropriate fallback cache as needed.
In this new workflow, adding a new runner to a GitLab group requires authorized users to create a runner in the GitLab UI and include essential configuration metadata. With this method, the runner is now easily traceable to the user, which will help administrators troubleshoot build issues or respond to security incidents.
The include keyword lets you compose your CI/CD configuration from multiple files. For example, you can split one
long .gitlab-ci.yml file into multiple files to increase readability, or reuse one CI/CD configuration file in multiple projects.
Previously, a single CI/CD configuration could include up to 150 files, but in GitLab 16.0 administrators can modify this limit to a different value in the instance settings.
In this new workflow, adding a new runner to a project requires authorized users to create a runner in the GitLab UI and include essential configuration metadata.
With this method, the runner is now easily traceable to the user, which will help administrators troubleshoot build issues or respond to security incidents.
projects/:id/jobs API endpoint reducedPreviously, the GET /api/:version/projects/:id/jobs was rate limited to 2000 authenticated requests per minute.
To move this in line with other rate limits and improve efficiency and reliability, we have lowered the limit to 600 authenticated requests per minute.
We’re also releasing GitLab Runner 16.0 today! GitLab Runner is the lightweight, highly-scalable 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.
The list of all changes is in the GitLab Runner CHANGELOG
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,
disabled 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.
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.
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.
]]>