GitLab.org/GitLab: Release v15.11.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 15.11
Released: 2023-04-22
License: MIT
Release Assets:


##### [Software supply chain security](https://about.gitlab.com/stages-devops-lifecycle/software_supply_chain_security/)
[Vulnerability dismissal reasons](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-dismissal-reasons) (SaaS only):
> In previous releases, you had to manually add a comment to specify why a vulnerability was dismissed.
> In GitLab 15.11, you can add a reason for dismissing a vulnerability to the Vulnerability Report.
> Now you can quickly and consistently track why vulnerabilities were dismissed.
>
> This feature is only available on GitLab.com. Support for self-managed instances is tracked in [this issue](https://gitlab.com/groups/gitlab-org/-/epics/4942).
Vulnerability Management
[Code Suggestions for Ultimate & Premium Users](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html) (SaaS only):
> Every day, millions of developers use GitLab to contribute code. In February, we launched a closed Beta of this feature, and since then, we’ve been working hard to make [Code Suggestions](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html) available to more developers. During Beta, Code Suggestions is free for all Ultimate and Premium customers. Group admins can enable this setting with a new [group-level control](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#group-level-setting). Depending on the prompt, the extension either provides entire code snippets, like generating functions, or completes the current line. To accept the suggestions, simply press Tab.
>
> GitLab Code Suggestions can improve developer productivity, focus, and innovation without context switching and within a single DevSecOps platform. Please note that this is a high-demand [Beta feature](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#beta) and may have unscheduled downtime. During Beta, it may also produce low-quality or incomplete suggestions. Read about [known limitations](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#known-limitations). We are continuously iterating to improve Code Suggestions and make it better. Give it a try, and [share your feedback with us](https://gitlab.com/gitlab-org/gitlab/-/issues/405152).
Code Suggestions
[Value Streams Dashboard released in Beta](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html):
> This new dashboard provides strategic insights into metrics that help decision makers to identify trends and patterns to optimize software delivery. The Beta release is focused on measuring software development ([DORA4](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html)) and the [flow of value delivery (Value Stream Analytics)](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) across projects and groups.
>
> Organizations can use the [Value Streams Dashboard](https://about.gitlab.com/blog/2023/01/24/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers/#gitlab-value-streams-dashboard) to identify workflow inefficiencies and opportunities for improvements by benchmarking key DevSecOps metrics.
>
> The Value Streams Dashboard offers visibility across every step of the software development lifecycle, without needing to buy or maintain a third-party tool.
Value Stream Management
, DORA Metrics
[Container Scanning outputs CycloneDX documents](https://docs.gitlab.com/ee/user/application_security/container_scanning/#cyclonedx-software-bill-of-materials):
> To align with a popular Software Bill of Materials (SBOM) industry format standard, the Container Scanning tool now outputs a CycloneDX SBOM for the scanned image. This CycloneDX SBOM is named `gl-sbom-report.cdx.json` and is saved in the same directory as the `JSON report file`. You can download CycloneDX SBOMs the same way as other job artifacts.
Container Scanning
[Dependency Scanning support for pnpm](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#obtaining-dependency-information-by-parsing-lockfiles):
> Thanks to a community contribution from [Weyert de Boer](https://gitlab.com/weyert-tapico), GitLab Dependency Scanning now supports analyzing JavaScript dependencies managed by the pnpm package manager.
Software Composition Analysis
[Automatic response to leaked secrets on any public branch](https://docs.gitlab.com/ee/user/application_security/secret_detection/post_processing.html):
> If you leak a secret in a public project, it's important to remediate it as soon as possible. Otherwise, an adversary can abuse your account.
>
> GitLab Secret Detection automatically responds to [some types of credential leaks](https://docs.gitlab.com/ee/user/application_security/secret_detection/post_processing.html) in public projects by revoking the credential or notifying the partner who issued it.
>
> Previously, this automatic protection only worked after you committed the secret on the default branch.
> Now, merge requests and other unmerged branches in public projects are also protected by the same automatic response.
Secret Detection
[Support for Yarn `v2` and `v3` in Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#obtaining-dependency-information-by-parsing-lockfiles):
> GitLab Dependency Scanning now supports analyzing dependencies defined in Yarn `v2` and `v3` lock files. This is currently limited to the dependencies downloaded from npm registries. [Other protocols available in Yarn](https://yarnpkg.com/features/protocols#table) are not supported.
Software Composition Analysis
[Manage project compliance frameworks report at group level](https://docs.gitlab.com/ee/user/compliance/compliance_report/#compliance-frameworks-report):
> Prior to GitLab 15.11, if you wanted to add or remove a compliance framework from a project, you needed to go to each project individually to
> manage which framework was associated with the project. When managing more than a few projects, this process was tedious and inefficient.
>
> Now, you can manage which compliance frameworks are applied to your projects at the group level, significantly reducing the amount
> of time needed to make sure your projects are adhering to the regulations and standards you are measured against.
>
> In GitLab 15.10, you could view all the projects in your group and see which ones had compliance frameworks applied to them. In GitLab 15.11, you can
> add or remove compliance frameworks directly from the compliance frameworks report.
Compliance Management
[Option to disable LDAP synchronization of user's name](https://docs.gitlab.com/ee/administration/auth/ldap/ldap_synchronization.html#synchronize-ldap-username) (self-managed only):
> You can now configure LDAP synchronization to **not** include the user's name. Previously, LDAP synchronization always included this information, making it impossible to change the name value in GitLab. This option is disabled by default.
User Management
[Multiple approval rules are available in the GitLab UI](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments):
> If you follow continuous delivery practices using GitLab approval rules, previously you had to pick between **Multiple approval rules**
> and **Unified approval rules**. Multiple approval rules are generally more flexible, but in past releases were only available through the API.
> [Approval rules settings pages](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments) now configure
> multiple approval rules.
>
> You can [access your previously configure unified approval rule settings](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#unified-approval-setting)
> through the GitLab API. We are looking into [automatically migrating Unified approval rules to Multiple approval rules](https://gitlab.com/gitlab-org/gitlab/-/issues/357798).
> The migration cannot support all the use cases and might be a breaking change for some users. For this reason, we recommend migrating manually.
Environment Management
[New visualization of stages breakdown in Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-custom-stages):
> We updated the [Value Stream Analytics overview](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) and replaced the **Total time** line chart with a stacked area chart. The new chart displays a breakdown of all stages, with the time items spent in each stage over a selected time period. This visualization simplifies the top-down optimization flow from the [Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard) to Value Stream Analytics, and helps you evaluate the progress of each stage at a glance.
Value Stream Management
[Kubernetes 1.26 support](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions):
> This release adds full support for Kubernetes version 1.26, released in December 2022. 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](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions) and other supported Kubernetes versions.
Deployment Management
[README files for groups](https://docs.gitlab.com/ee/user/group/manage.html#add-group-readme):
> Previously, README files were available only at the project level. Now, they're available at the group level too. As a group owner or member, you can use a README to provide more information about your team and invite users to contribute to your projects. In your group overview, selecting the **Add README** action creates a new project (`gitlab-profile`) that contains the `README.md` file. The README is displayed on the group overview page, and can be changed in the group settings.
Subgroups
[Documentation for using the agent for Kubernetes with custom certificates](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#environments-with-kas-that-use-self-signed-certificates):
> GitLab 15.11 adds documentation to help you configure the agent for Kubernetes when GitLab runs with a CI/CD integration and custom certificates. The documentation includes steps to set up KAS and `agentk`, and to invoke `kubectl` commands from GitLab CI/CD.
Deployment Management
[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - GitLab 15.11 introduces [support for Kubernetes 1.25](https://docs.gitlab.com/charts/installation/cloud/).
Cloud Native Installation
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 15.11 includes [Mattermost 7.9](https://mattermost.com/blog/mattermost-v7-9-is-now-available/). This version includes
> [security updates](https://mattermost.com/security-updates/) so you should upgrade from earlier versions.
> - In GitLab 16.0, the minimum supported version of PostgreSQL will become 13. Therefore, in 15.11 we will swap `attempt_auto_pg_upgrade?` to `true`. This function will attempt to automatically upgrade the version of PostgreSQL to 13 in 15.11 in preparation for the new minimum PostgreSQL requirement in 16.0. This is the same behavior we performed in preparation for the last minimum upgrade of PostgreSQL.
Omnibus Package
[Set custom Git server hooks using CLI](https://docs.gitlab.com/ee/administration/server_hooks.html#set-server-hooks-for-a-repository) (self-managed only):
> In previous versions of GitLab, administrators needed to directly access the file system that stored a repository to add custom Git server hooks.
>
> Now, administrators can set Git server hooks for a repository using the new the `hooks set` command in the Gitaly CLI. The Gitaly CLI command targets an individual Gitaly
> node and applies the provided custom Git server hooks to the specified repository. You can use this to programmatically roll out Git server hooks across repositories in Gitaly.
>
> All existing Git server hooks continue to function. However, `hooks set` is the only way to configure new Git server hooks in GitLab 15.11 and later.
>
> `hooks set` does not yet work for Gitaly Cluster, but this effort paves the way for us to automatically replicate Git server hooks in Gitaly Cluster. Please follow that
> effort in [issue 5018](https://gitlab.com/gitlab-org/gitaly/-/issues/5018).
Gitaly
[Migrate GitLab projects by direct transfer using API](https://docs.gitlab.com/ee/api/bulk_imports.html#start-a-new-group-migration):
> Until now you could migrate GitLab projects by direct transfer only when migrating GitLab groups. If some projects failed to be migrated, you couldn't
> try to import only failed projects again. The workaround was to import chosen projects by uploading export files, which imports only
> one project at a time.
>
> With this release, you can migrate projects by direct transfer using the API. You can use this to re-import only the chosen failed project. This also
> lays the groundwork for this feature to be made available in the UI.
Importers
[Detailed link preview visible for non-publicly available pages](https://docs.gitlab.com/):
> Previously, when a user selected a non-public GitLab link, the link preview did not work due to the lack of OpenGraph and Twitter meta HTML tags for the sign-in page. These tags have been added, and now the preview is visible when a user selects a non-public GitLab link.
>
> Thank you [Anatoly Ubiyko](https://gitlab.com/aubiyko) for your contribution!
System Access
[Better error message when direct transfer setting is disabled](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer):
> GitLab group and project migration by direct transfer requires that both GitLab instances have the feature enabled in application settings by
> an instance administrator. Until now, if you tried to initiate an import when the feature was disabled on the source instance, you received a `404`
> error.
>
> We've replaced the `404` error with an informative message, and provided guidance on how to enable the feature.
Importers
[Improved data sync between Jira and GitLab for Jira Cloud app](https://docs.gitlab.com/ee/integration/jira/development_panel.html#information-displayed-in-the-panel):
> In GitLab 15.11, we have improved syncing of both existing and new data between Jira Cloud and the GitLab for Jira Cloud app.
>
> Previously, when you added a namespace to the GitLab for Jira Cloud app, only existing merge request data was synced to Jira. Now, existing branch and commit data is also synced.
>
> When you viewed a Jira issue, the GitLab for Jira Cloud app previously showed related GitLab branches only if the branch name contained the Jira issue ID (for example, `my-branch-JIRA-1`). The GitLab for Jira Cloud app now also links to GitLab branches when you mention the Jira issue ID in the merge request title or description.
Integrations
[Award achievements to users](https://docs.gitlab.com/ee/user/profile/achievements.html):
> Using achievements, users can now acknowledge the accomplishments of others and reward the effort and skill that they have demonstrated. You can now receive achievements for your contributions on GitLab, and display them on your user profile. An achievement consists of a name, a description and an avatar. Users with the Maintainer or Owner role can create custom achievements, award them to users meeting the achievement criteria, and revoke them if they no longer meet the criteria. Up to three of your most recent achievements will display underneath your profile image on your user profile page. If you prefer not to display achievements on your profile, you can opt out in the user profile settings.
>
> In 15.11, we are releasing a Beta of this capability behind a feature flag. If you want to try it out on self-managed GitLab, ask your administrator to enable it. For GitLab.com, please request access in the [feedback issue 405153](https://gitlab.com/gitlab-org/gitlab/-/issues/405153).
>
> We hope that this change will increase productivity and engagement in organizations, and motivate team members to showcase their skills and accomplishments. Please share your experiences in [issue 405153](https://gitlab.com/gitlab-org/gitlab/-/issues/405153).
User Profile
[Google Play Store integration](https://docs.gitlab.com/ee/user/project/integrations/google_play.html):
> From GitLab 15.11, you can configure and validate your projects with Google Play Store credentials. You can then use those credentials in CI/CD pipelines to automate releases to the Google Play Store.
>
> To record your experiences with the Google Play Store integration, see this [feedback issue](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/feedback/-/issues/13).
Continuous Delivery
[Open modified files in the Web IDE Beta](https://docs.gitlab.com/ee/user/project/web_ide_beta/#use-when-viewing-a-merge-request):
> The Web IDE Beta allows you to review merge requests and make additional changes to new and modified files without cloning the project to your local machine. However, when launched from a merge request, the Web IDE Beta previously didn't open any of these files.
>
> To make it easier to contribute, new and modified files now appear in separate tabs when you open the Web IDE Beta from a merge request. Each file is presented with inline diffs so you can review the changes immediately. To optimize performance, the Web IDE Beta only opens the top 10 files (by number of lines changed) in a merge request. In the file tree, any new or modified file is indicated by an icon next to the filename.
Web IDE
[Web IDE Beta enabled by default on self-managed](https://docs.gitlab.com/ee/user/project/web_ide/) (self-managed only):
> The Web IDE Beta brings powerful new capabilities and dramatically improved performance to the web-based code editor. The Web IDE Beta has been available for self-managed instances since GitLab 15.7, but was disabled behind a feature flag.
>
> From GitLab 15.11, the Web IDE Beta is now the default editor for all self-managed instances. You can opt out of the Web IDE Beta any time in your user preferences.
Web IDE
[Rerun downstream pipeline trigger jobs](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#recreate-a-downstream-pipeline):
> Previously, if you needed to trigger a rerun of an entire downstream pipeline, you had to rerun the full upstream pipeline. This could be a time-consuming and inefficient process, especially if the upstream pipeline has many jobs or other downstream pipelines.
>
> In this release, we've added the ability to rerun just the downstream pipeline, without having to re-run the entire parent pipeline, by selecting **Run again** on the trigger job. The newly triggered downstream pipeline replaces the original downstream pipeline in the pipeline graph. This will save you time and resources when you want just the downstream pipeline to run again.
Pipeline Composition
[Define inputs for included CI/CD configuration](https://docs.gitlab.com/ee/ci/yaml/includes.html#define-inputs-for-configuration-added-with-include-beta):
> Previously, if you wanted to change the behavior of included CI/CD configuration, like a CI/CD template, you may have used global CI/CD variables.
> However, using global variables applies to the entire pipeline, not just the included configuration, which was not always desirable.
>
> This release adds the ability to declare mandatory or optional input parameters for each includable configuration file.
> These input parameters replace the need for global variables and are scoped to the included configuration only, having no impact on the rest of the pipeline.
> This allows you to build more robust and isolated CI/CD templates, as well as declare and enforce constraints. Learn how to use CI interpolation in this [example repo](https://gitlab.com/grzesiek/ci-interpolation-example).
Pipeline Composition
[Import NuGet packages by using CI/CD pipelines](https://docs.gitlab.com/ee/user/packages/package_registry/#to-import-packages):
> Have you been thinking about moving your NuGet registry 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 NuGet package importer. You can now use the Packages Importer tool to import packages from any NuGet 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.
Package Registry
[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> 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.11 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - CodeClimate analyzer updated to version 0.94.0. See [CHANGELOG](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/CHANGELOG.md#anchor-0940) for further details.
> - Brakeman-based analyzer updated to version 5.4.1. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman/-/blob/master/CHANGELOG.md#v320) for further details.
> - KICS-based analyzer updated to version 1.6.13. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v3710) for further details.
> - KubeSec-based analyzer updated to version 2.13.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec/-/blob/master/CHANGELOG.md#v346) for further details.
> - Secrets analyzer updated to version 8.16.2. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v4515) for further details. We also added new rules:
> - Google Cloud OAuth client secrets.
> - GitLab [feed tokens](https://docs.gitlab.com/ee/security/token_overview.html#feed-token).
> - Digital Ocean tokens.
> - Security Code Scan-based analyzer updated to add support for .NET 7 by default. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/blob/master/CHANGELOG.md#v391) for further details.
> - Semgrep-based analyzer updated to version 1.17.1. We also fixed a parsing error related to Go [false positive detection](https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection). See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v3145) for further details.
> - Thanks to [`@jnoordsij`](https://gitlab.com/jnoordsij) for this community contribution.
> - Sobelow-based analyzer updated to version 0.12.2. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/blob/master/CHANGELOG.md#v3210) 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/2023/03/22/gitlab-15-10-released/#static-analysis-analyzer-updates).
Code Quality
, SAST
, Secret Detection
[Warnings to prevent accidental token leaks in issues, MRs, and comments](https://docs.gitlab.com/ee/user/application_security/secret_detection/#warnings-for-potential-leaks-in-text-content):
> When you create an issue, propose a merge request, or write a comment, you might accidentally post a sensitive value.
> For example, you might paste in the details of an API request or an environment variable that contains an authentication token.
>
> Now, GitLab checks if the text of your issue, merge request description, comment, or reply contains a token.
> If a token is found, a warning message is displayed. You can then edit your message before it's sent to the server to be posted.
>
> This new protection is always on; you don't have to set it up.
> Currently, it checks for GitLab [Personal Access Tokens](https://docs.gitlab.com/ee/security/token_overview.html#personal-access-tokens) (PATs) and [Feed Tokens](https://docs.gitlab.com/ee/security/token_overview.html#feed-token).
> Further improvements are considered in [issue 405147](https://gitlab.com/gitlab-org/gitlab/-/issues/405147).
Secret Detection