This change helps you focus on the vulnerabilities that are still relevant after the rule update.
Previously, when a rule was no longer scanned, its findings would be marked “No longer detected” but you still had to take action to resolve them.
Now, the Vulnerability Management system automatically resolves those findings and leaves a comment explaining that the rule was removed, so you still have a historical record of the vulnerability.
This change will automatically resolve findings from a small number of rules that we’ve replaced or removed in recent releases.
This feature is enabled by default on GitLab.com and in GitLab 15.10.
On GitLab.com, contact Support if you need to disable the flag for your project.
On GitLab self-managed, you can disable the project-level feature flag named sec_mark_dropped_findings_as_resolved.
From GitLab 15.10, you can configure and validate your projects with Apple App Store credentials. You can then use those credentials in CI/CD pipelines to automate releases to Test Flight and the App Store.
To record your experiences with the App Store integration, see this feedback issue.
All branch-related protections now display on a single page. To see a unified list of your branches and all their protection methods, go to Settings > Repository > Branch rules. Each branch shows the merge request approvals, security approvals, protected branches, and status checks configured for it. Previously, these settings were grouped by type, making it tough to see a holistic view of a specific branch’s protections.
We hope this change helps you discover, use, and monitor these settings more easily. We’d love your feedback in issue #388149.
Identifying commits that have been tagged just got simpler. View the commits list at Repository > Commits to see commits with their tags attached. This view helps you understand what commits have been added since a tagged release commit.
With GitLab 15.10, you can more easily create and edit diagrams in wikis by using the diagrams.net GUI editor. This feature is available in the Markdown editor and the content editor, and was implemented in close collaboration with the GitLab wider community.
When you open the Web IDE Beta from a repository or merge request, the currently selected branch is used by default. You can create a new branch with your changes or, if you’re not on a protected branch, commit to the current branch. Starting with GitLab 15.10, you can now also create a new branch any time while making changes or switch branches in the Web IDE Beta. This way, you can boost your productivity by not having to close the Web IDE Beta to switch contexts.
Since release in closed beta, Suggested Reviewers has been enabled in over 1,000 projects and suggested over 200,000 reviewers. We’ve also made the service more reliable and are now making it generally available to all Ultimate customers.
Deciding the right person to review your merge request isn’t always straightforward or obvious. Choosing the wrong reviewer can cause delays, low quality reviews, back and forth reassigning reviewers, or even no review at all.
Now, GitLab can recommend a reviewer with Suggested Reviewers. Using the changes in a merge request and a project’s contribution graph, machine learning powered suggestions appear in the reviewer dropdown in the merge request sidebar. Suggested Reviewers is our first—of many—fully available ML feature at GitLab.
To protect GitLab and users across the system from any potential abuse or misuse, we’ve implemented a feature to disable group webhooks that fail consistently.
Group webhooks that return response codes in the 5xx range are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours.
Group webhooks that fail with 4xx errors are permanently disabled.
Users with the Owner or Maintainer role are alerted in the app to investigate and re-enable any failed group webhooks.
By default, this feature is enabled on GitLab.com and disabled on self-managed GitLab. To enable automated disabling of failed webhooks for project or group webhooks, administrators of self-managed instances must enable the auto_disabling_web_hooksfeature flag.
This release includes a new section dedicated to browsing and discovering various content within GitLab. This new section, called Explore, helps you view and search across different content types. Previously, it was difficult to switch between types while searching for content.
Also with this change, the Topics section is elevated to the Explore section. This change should better accommodate the feature and its discoverability. This change helps promote open source while helping you find content related to topics you are interested in.
The OpenID Connect (OIDC) OmniAuth provider for authentication in GitLab now supports group claims for administrator, external, and required groups. This is consistent with our SAML implementation, and administrators can use OIDC and group claims to manage upstream user access to GitLab.
When migrating GitLab groups and projects, errors listed as import failures on the group Import history page were not always informative enough.
We now include errors from all nested subrelations to make it clear why a relation (for example, a merge request), failed to import. Better error
messages support debugging and speed up resolution time.
To protect against the risk of data loss and exposure, GitLab administrators can now use outbound request filtering controls to safely manage their instances. With this setting, you can block all requests and define accepted IP addresses and domains in an allowlist to establish secure routes for outbound traffic.
SAML group lock allows GitLab administrators to prevent additional members being added to groups that are controlled by SAML group links. Previously, if SSO enforcement was enabled, a group Owner could add a non-group user to their group if that user has signed in using SSO. If SSO enforcement was not enabled, a group Owner could add any non-group user to their group. Now, if SAML group lock is enabled, users can only be added using SAML group links.
Previously, the GraphQL API supported only one metric per request. Now, it supports multiple DORA metrics in the same request. This change improves performance when querying DORA metrics data.
Gitlab’s DORA metrics help executives who are investing in DevOps transformation to understand the ROI on processes they are implementing and tools they have purchased. The teams can use the changes in these metrics as KPIs.
You can report abuse from other GitLab users to GitLab administrators. Previously, you could report specific comments, for example, in issues and merge requests.
Now you can also report comments in epics.
Define a default code owner for each section of your CODEOWNERS file. This default
now applies to files and directories referenced in the section. This way you don’t
have to repeat the same owners over and over. Individual files and directories can
still be overridden.
In this example, all files and directories are owned by @dev-team, except README.md
and the data-models/ directory.
Merge Trains allow you to sequence merge requests (MRs) and verify their changes work together before they are merged to the target branch. Previously, to add an MR to a merge train, you had to click a button on the MR’s page in the GitLab UI. This method did not support CI/CD automation or other flows that some organizations might want to implement.
Now you can add a merge request to a merge train by using the merge trains API, enabling more control through automation.
GitLab Dependency Scanning now supports a new DS_MAX_DEPTH variable to allow users to scan their entire repository for lock files. This variable defaults to only scanning up to two directories deep by default; however, users can set the variable to a larger number or to a value of -1 to scan their entire repository.
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.
KICS-based analyzer updated to version 1.6.11. See CHANGELOG for further details. This version includes new rules, bug fixes, and improvements.
PMD Apex-based analyzer updated to version 6.54.0. See CHANGELOG for further details.
Secrets analyzer updated with new rules. See CHANGELOG for further details. New rules include:
Sendinblue SMTP tokens, thanks to a community contribution from @ohemelaar.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
Users with the Owner role for a project can now use the GraphQL API to change the maximum access level of non-inherited users of a project. This release brings more administrative features to users with the Owner role for projects on GitLab.com, and lays the foundation for future administrative bulk actions.
GitLab 15.10 introduces a new certificates container certificates built off of gitlab-base. Previously, they were built on top of Alpine Linux and named alpine-certificates.
GitLab 15.10 also introduces smaller images for Cloud Native UBI8. These images have been made smaller by adopting UBI Minimal allowing for more rapid deployments. This is part of a larger initiative to reduce the number and severity of vulnerabilities across GitLab container images.
In GitLab 15.10, we also introduce new public version manifests for Omnibus GitLab. The version manifest file shows the top level software versions, and importantly, where those versions can be fetched from. These files may need to be readily available for different cloud-deploy requirements, so now our release pipelines will generate a public manifest version.
Omnibus installations of GitLab run the Kubernetes Agent Server (KAS) on the main GitLab domain. To stay consistent with the GitLab chart installation method, you can now serve KAS to Omnibus installations on a dedicated subdomain.
The KAS address /-/kubernetes-agent on the main GitLab domain remains the default setting.
Set the syntax highlighting theme shown to new users, or users who are viewing code but not signed in. Previously, the default only applied to signed-in users, causing signed-out users to sometimes see a visual clash between dark and light theme highlighting.
Until now, imported GitHub projects didn’t have their collaborators imported with them. This meant that no users had any
permissions on these projects. As a workaround, group owners would add members before the import.
Now, if a collaborator’s role can be mapped to a GitLab role, GitLab adds the GitHub collaborator to the imported project as a GitLab project member.
When users are provisioned with SAML or SCIM, the link in their email confirmation now directs them to sign in through their identity provider. Previously, users were directed to the GitLab sign-in page, which was potentially confusing.
GitLab sends a notification email when your account is signed into from an unknown location. Previously, this email did not include name information, making it difficult to tell which account the notification was associated with. This notification email now includes both the user’s full name and username.
Previously, you had to use a time-based one-time password (TOTP) before you could add a WebAuthn device as a two-factor authentication (2FA) method on your GitLab account. Now, you can add a WebAuthn device as your 2FA method without having to use a TOTP. You must download recovery codes when adding a WebAuthn device as your 2FA method so you can recover access to your account if you are locked out.
To improve the tracking of development workflows in Value Stream Analytics, we added a new pairing rule for customizable stages between MR label events and MR merged events. This rule makes it possible to create a custom stage that, for example, measures the time from when an MR was labeled as workflow::in review to when it was merged.
Before this release, there was no way to see a detailed change log for a task or have discussions directly with team members. Tasks now show system notes and support collaborating with comments and threads.
We’re also releasing GitLab Runner 15.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.
The new method of License Compliance scanning is now fully supported for self-managed GitLab instances, including instances that are running in an offline environment. This feature is behind two feature flags that are disabled by default. To try this feature, enable the license_scanning_sbom_scanner and package_metadata_synchronization feature flags, and replace the Jobs/License-Scanning.gitlab-ci.yml template in your CI configuration with the Jobs/Dependency-Scanning.gitlab-ci.yml template. In GitLab 16.0 and later, the old method of scanning with the Jobs/License-Scanning.gitlab-ci.yml template will no longer be supported.
Customer support agents often send screenshots and other files to external Service Desk issue authors.
However, if your GitLab instance is not reachable from the internet or if you are using a private project that requires
authentication to access issue uploads, issue authors won’t be able to access the assets.
In this release, files up to 10 MB attached to comments on Service Desk issues are sent to external participants as native email attachments.
This allows external issue authors to access the
assets directly in their inboxes without having to access the attachments through GitLab.
Users can now require SAST IaC scans to run on a regular schedule or as part of project CI pipelines, independent of the .gitlab-ci.yml file’s contents. This allows security teams to manage these scan requirements separately, without allowing developers to change the configuration. You can get started by creating a scan execution policy on the Security & Compliance > Policies page.
With this release, Geo now automatically verifies the data integrity of a replicated Container Registry. This ensures that container images are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects you against data loss.
When editing a project in the Admin Area, users are currently redirected to the project settings page of the respective project.
This redirect requires several clicks to return to the original list of of projects, thus making it cumbersome for an administrator who tries to edit multiple projects.
To improve this workflow, a new project edit page is introduced that allows administrators to stay in the Admin Area when editing a project, and to return to the project list with just one click.
You can now filter code search results by one or more languages. The new filter uses Elasticsearch aggregations to help you narrow down the results to specific programming languages. To use this feature, Advanced Search must be enabled.
The GitLab agent for Kubernetes manages access with agent access tokens. Because they can be used to update your cluster from GitLab, you should regularly rotate your agent tokens. GitLab now triggers audit events when the agent access tokens are created or revoked to support your security and compliance requirements.