GitLab.org/GitLab: Release v15.8.0-ee

Name: GitLab

Released: 2023-01-22

License: MIT

Release Assets:

![21 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=21&style=for-the-badge "New features added in this release") ![2825 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=2825&style=for-the-badge "Total features")

[Migrating GitLab projects by direct transfer Beta](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended) (SaaS only): Importers

> We are excited to announce the availability of migrating GitLab projects by direct transfer Beta. Now, you can migrate group and project resources together when using direct transfer. You can use direct transfers to migrate between GitLab instances or > within the same GitLab instance. > > Migrating projects when [migrating groups using direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended) is a major > improvement from migrating groups and projects using [file exports](https://docs.gitlab.com/ee/user/project/settings/import_export.html) because: > > - You don't need to manually export each project to a file and then import all those export files to a new location. Now all projects > within a top-level group are migrated automatically, making your work more efficient. > - When migrating from self-managed GitLab to GitLab.com, user associations (such as comment author) are not changed to the user who is importing the > projects. Migration using direct transfer maps users and their contributions correctly, provided > [a few conditions are met](https://docs.gitlab.com/ee/user/group/import/#preparation). > > This feature is available on GitLab.com. You can migrate from a self-managed GitLab to GitLab.com > right now! > > To enable it on GitLab self-managed instances, see the linked documentation. > > Learn more about migrating GitLab projects by direct transfer Beta and what’s coming next in our recent [blog post](https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-migrate-projects/).

[Selective SSO enforcement for group members](https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement) (SaaS only): System Access

> 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. A member has a SAML identity if one or both of the following are true: > > - They signed in to GitLab using their GitLab group's single sign-on URL. > - They were provisioned by SCIM. > > Users without SAML identities are not required to use SSO unless SSO enforcement is explicitly enabled. > > To ensure smooth operation of the selective SSO enforcement feature, please ensure your SAML configuration is > working properly before selecting the **Enable SAML authentication for this group** checkbox.

##### [Software supply chain security](https://about.gitlab.com/stages-devops-lifecycle/software_supply_chain_security/)

[Block merges unless external status checks pass](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html#block-merges-of-merge-requests-unless-all-status-checks-have-passed) (SaaS only): Compliance Management

> You can now configure projects to block merge request merges unless all external status checks pass. This allows you to confidently > rely on external systems as part of your GitLab workflows and ensure that all required steps are completed before the code is merged. > > When configured, users can only merge merge requests if external status checks pass and the green checkmark is displayed on the merge request. If an > external status check is pending or failed, merging the merge request is blocked. > > This feature is available to self-managed users, but is not enabled by default. You can enable this feature in Gitlab 15.5 and later with the `only_allow_merge_if_all_status_checks_passed` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#how-to-enable-and-disable-features-behind-flags). This feature is now enabled by default in GitLab 15.8 for SaaS users and will be enabled by default in GitLab 15.9 for self-managed users.

#### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![2 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=2&style=flat-square "New features added to this tier in this release") ![376 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=376&style=flat-square "Total features in this tier") ##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)

[View estimated queuing time for runners in the Admin Area](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#view-statistics-for-runner-performance) (self-managed only): Runner Fleet

> A key input in GitLab Runner fleet optimization is having deep insights into queue performance over time. While today there are historical queue duration metrics available for each job on a runner in the Admin Area view, there is no simple mechanism to determine the current queue performance for runners. > > With the new estimated queue time feature, you are now able to, at a glance, determine the median estimated wait time for all instance runners. This data will enable you to proactively identify potential CI job execution issues for your organization's developers and provide insights to inform decisions on configuration or resource changes to optimize your runner fleet.

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[SAST false positive detection now supports Go](https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection): SAST

> GitLab SAST uses proprietary technology to identify [likely false positive results](https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection) that open-source scanners return. > We've added Go support in addition to existing support for Ruby.

#### [Premium](https://about.gitlab.com/pricing/premium/) ![3 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=3&style=flat-square "New features added to this tier in this release") ![532 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=532&style=flat-square "Total features in this tier")

[More discoverable syntax options for Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html#syntax): Global Search

> In this release, we've added a **Syntax options** link to the search page to help you with complex queries. The drawer content provides syntax options for [Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html) and serves as a quick reference for you when typing a query.

[Audit event for changing protected status of an environment](https://docs.gitlab.com/ee/administration/audit_events.html): Audit Events, Environment Management

> GitLab now records audit events when an environment is set to protected and when it is unprotected. A protected environment is typically used for high-risk deployments, so it's important to have an audit trail for when protection is removed or added.

[SCIM support for self-managed GitLab](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) (self-managed only): User Management

> Self-managed GitLab now supports the open standard System for Cross-domain Identity Management (SCIM), which allows you to automatically: > > - Create users. > - Remove users by deactivating their SCIM identities. > > Previously, this was only available for GitLab.com. SCIM enables GitLab administrators to completely automate their user lifecycle management.

#### Core ![13 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=13&style=flat-square "New features added to this tier in this release") ![1868 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=1868&style=flat-square "Total features in this tier")

[Setting for enabling group migration by direct transfer](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer) (self-managed only): Importers

> As part of group migration by direct transfer with project migration (in Beta), we have added a > [new application setting](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer) so that > GitLab self-managed administrators can more easily enable this feature. Previously, administrators had to use feature flags to enable this feature. > > This new setting must be enabled on both the source and target instances. Remember to also enable the `bulk_import_projects` feature flag if you > want to migrate projects with your groups.

[Populate **Allowed to push** branch protection rule on GitHub imports](https://docs.gitlab.com/ee/user/project/import/github.html#branch-protection-rules-and-project-settings): Importers

> When importing projects from GitHub to GitLab, the GitLab [**Allowed to push** branch protection rule](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#configure-a-protected-branch) is set if the following conditions are met in the GitHub project: > > - The **Require a pull request before merging** setting is set. > - The **Allow specified actors to bypass required pull requests** setting lists some users. > > If the group you are importing your project to: > > - Has at least a Premium license, GitLab users populate the list of users that are allowed to push. > - Doesn't have at least a Premium license, the list of users that are allowed to push is limited to roles.

[Create To-Dos for group owners on access request](https://docs.gitlab.com/ee/api/todos.html#get-a-list-of-to-do-items): Subgroups, User Management

> Previously, access requests to a group appeared only in the **Access** requests tab in the **Group members** section. Now, access requests also appear in the group owner's To-Do List. As a group owner, having access requests added directly to your To-Do List can help you manage your tasks more efficiently and add members quicker.

[Create To-Dos for project owners on access requests](https://docs.gitlab.com/ee/user/todos#actions-that-create-to-do-items): Projects, User Management

> Previously, access requests to a project appeared only in the **Access** requests tab in the **Project members** section. Now, access requests also appear in the project owner's To-Do List. As a project owner, having access requests added directly to your To-Do List can help you manage your tasks more efficiently and add members quicker.

[Option to not include projects when migrating GitLab groups](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended): Importers

> Previously when migrating a GitLab group with direct transfer to GitLab.com, you had to migrate its projects as well. > > Now you have the option to not include projects when migrating groups. This option is available in the UI and the API and you can choose > this option for each group separately or for all selected groups at once. The default is to a migrate group with its projects.

[Import GitHub gists into GitLab snippets using API](https://docs.gitlab.com/ee/api/import.html#import-github-gists-into-gitlab-snippets): Importers

> Previously, you could import GitHub repositories to GitLab but couldn't import GitHub gists as well. > > Now you can use GitLab REST API to import your [personal gists](https://docs.github.com/en/rest/gists/gists#list-gists-for-the-authenticated-user) (with no more than 10 files) into > [personal GitLab snippets](https://docs.gitlab.com/ee/user/snippets.html#create-snippets). These appear on your [snippets dashboard](https://gitlab.com/dashboard/snippets). > > Gists with more than 10 files are skipped and must be manually copied over. > > If any gists were skipped or did not import for any other reason, you receive an email with the list of gists that could not be imported and reason for the import failure.

[Check personal access token before migrations start](https://docs.gitlab.com/ee/user/group/import/#connect-to-the-source-gitlab-instance): Importers

> Previously, GitLab validated personal access tokens only after migrations had started. This meant group migrations by direct transfer > could fail mid-migration because the personal access token didn't have sufficient scope or was no longer valid. > > Now we perform an early check and return an informative error when the scope is not sufficient or the token has expired. This avoids starting > migrations that will definitely fail.

[Include expiring token's name in email notification](https://docs.gitlab.com/ee/user/profile/notifications.html): System Access

> When a personal access token expires, you are sent an email notification. Previously, this email told you that the token expired, but did not provide the token name. This email now provides the token name, so you can identify which token expired.

[Introducing two new fonts for GitLab](https://about.gitlab.com/blog/2023/01/17/new-typefaces-in-gitlab/): Design System

> GitLab has historically relied on system fonts, like San Francisco on macOS and Segoe UI on Microsoft Windows, for text in the user interface (UI). There are, however, limitations to using these, as each system font renders differently, and there are variations that can impact your experience with GitLab. > > In the recent GitLab rebranding, we selected [Inter](https://rsms.me/inter/) as the primary typeface, and we've adapted it for use in the GitLab UI by enabling disambiguation features (increased distinction between some characters) by default. Because of this change, we're including it under the name **GitLab Sans** in the open source package of GitLab. > > We've also chosen **JetBrains Mono** for our code editors and any UI requiring monospaced text. You can read more about the design process for this font in the blog post and leave feedback [here](https://gitlab.com/gitlab-org/gitlab/-/issues/386205).

[Setting to make user profiles private by default](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-profiles-of-new-users-to-private-by-default) (self-managed only): User Profile

> Newly created user profiles can now be made private by default. This instance-wide setting helps to comply with local data privacy laws and individual company agreements, for example with a works council. Users can still change the visibility of their profile page from the profile settings, and GitLab administrators can override this setting to make new profiles public.

##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)

[GitLab Runner 15.8](https://docs.gitlab.com/runner): GitLab Runner Core

> We’re also releasing GitLab Runner 15.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. > > #### Bug Fixes: > > - [CI_JOB_STATUS always shows running when FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY is set to false](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27693) > - [Jobs timeout seeking artifacts](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29281) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/15-8-stable/CHANGELOG.md).

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): Code Quality, SAST, Secret Detection

> GitLab Static Analysis includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.8 release milestone. These updates bring additional coverage, bug fixes, and improvements. > > - CodeClimate-based analyzer updated to version 0.89.0. See [CHANGELOG](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/CHANGELOG.md#anchor-0890) for further details. > - This version also adds support for setting `DOCKER_CONFIG` as an alternative to `CI_REGISTRY_USERNAME` and `CI_REGISTRY_PASSWORD` variables, thanks to a community contribution from [`@bitcasso`](https://gitlab.com/bitcasso). > - KICS-based analyzer updated to version 1.6.6. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v375) for further details. This version improves existing rules. > - Kubesec-based analyzer updated to automatically fetch Helm dependencies in Helm projects. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec/-/blob/master/CHANGELOG.md#v342) for further details. > - NodeJSScan-based analyzer updated to improve error logging. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/blob/master/CHANGELOG.md#v342) for further details. > - Semgrep-based analyzer updated to version 1.3.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v3111) for further details. > - SpotBugs-based analyzer updated to fix an error where invalid line numbers could prevent vulnerabilities from being reported. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v332) for further details. > > If you [include the GitLab-managed SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)), you don't need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. > > To remain on a specific version of any analyzer, you can [pin to a minor version of an analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). 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. > > For previous changes, see [last month's updates](https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/#static-analysis-analyzer-updates).

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[Promote an issue to an incident with a quick action](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#promote-an-issue-to-an-incident): Incident Management

> With this release, when you [create an issue](https://docs.gitlab.com/ee/user/project/issues/create_issues.html), you can set the issue type to an incident on creation with the `/promote_to_incident` quick action. > > Create an issue template and include this quick action in the description, and you will no longer have to manually select the issue type from the dropdown.