GitLab.org/GitLab: Release v16.0.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 16.0
Released: 2023-05-30
License: MIT
Release Assets:
##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)
[Upsizing GitLab SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html) (SaaS only):
> 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](https://docs.gitlab.com/ee/ci/pipelines/compute_minutes.html#cost-factor).
>
> We're excited to see pipelines run faster and boost productivity.
GitLab Runner SaaS[GPU-enabled SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#gpu-enabled-saas-runners-on-linux) (SaaS only):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/403008). We can't wait to hear your feedback!
GitLab Runner SaaS[Apple silicon (M1) GitLab SaaS runners on macOS - Beta](https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html#example-gitlab-ciyml-file) (SaaS only)
> Mobile DevOps teams can now run their entire CI/CD workflows on Apple silicon (M1)
> [GitLab SaaS runners on macOS](https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner)
> 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.
[Error Tracking is now generally available](https://docs.gitlab.com/ee/operations/error_tracking.html) (SaaS only):
> 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](https://docs.gitlab.com/ee/operations/error_tracking.html#integrated-error-tracking) and the
> [Sentry-based](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking) backends.
Error Tracking[AI-powered workflow features](https://docs.gitlab.com/ee/development/ai_features.html) (SaaS only):
> 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](https://about.gitlab.com/solutions/ai/)
Code Suggestions, Workflow Automation, Intelligent Code Security[Code Suggestions improvements](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html) (SaaS only):
> 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](https://about.gitlab.com/blog/2023/05/16/code-suggestions-for-all-during-beta/).
Code Suggestions[Value Streams Dashboard is now generally available](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html):
> This [new dashboard](https://youtu.be/EA9Sbks27g4) 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](https://docs.gitlab.com/ee/user/group/value_stream_analytics/), [DORA4](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html)),
> and [vulnerabilities](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) metrics.
>
> Organizations can use the [Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html)
> 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.
Value Stream Management, DORA Metrics[Introducing Out-of-band Application Security Testing through browser-based DAST](https://docs.gitlab.com/ee/user/application_security/breach_and_attack_simulation/#extend-dynamic-application-security-testing-dast):
> 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](https://docs.gitlab.com/ee/user/application_security/breach_and_attack_simulation/#extend-dynamic-application-security-testing-dast) configuration to enable callback attacks.
>
> In this release we are introducing the [BAS.latest.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/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](https://gitlab.com/gitlab-org/gitlab/-/issues/404809) on the addition of callback attacks to browser-based DAST.
DAST[Browser-based DAST performance improvements](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html):
> 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:
>
> - Added log summary statistics to help determine where time is spent during a scan. This can be enabled by including the environment variable `DAST_BROWSER_LOG="stat:debug"`.
> - Optimized passive checks by running them in parallel.
> - Optimized passive checks by caching regular expressions used when matching content in HTTP response bodies.
> - Optimized how DAST determines whether a page has finished loading. Now, we don't wait for excluded document types or out-of-scope URLs.
> - Reduced waiting time for pages where the DOM stabilizes quickly after page load.
>
> 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.
DAST[Security training with SecureFlag](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities):
> 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.
Vulnerability Management[Provide a reason when dismissing vulnerabilities in bulk](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#change-status-of-vulnerabilities):
> 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."
Vulnerability Management[Add and remove compliance frameworks without using bulk actions](https://docs.gitlab.com/ee/user/compliance/compliance_report/#apply-a-compliance-framework-to-projects-in-a-group):
> In GitLab 15.11, we added bulk [adding](https://docs.gitlab.com/ee/user/compliance/compliance_report/#apply-a-compliance-framework-to-projects-in-a-group) and
> [removing](https://docs.gitlab.com/ee/user/compliance/compliance_report/#remove-a-compliance-framework-from-projects-in-a-group) 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.
Compliance Management[Filter compliance violations by target branch name](https://docs.gitlab.com/ee/user/compliance/compliance_report/#view-the-compliance-violations-report-for-a-group):
> 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.
Compliance Management[Support role-based approval action for scan result policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html):
> 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.
Security Policy Management[Delayed group and project deletion set as default](https://docs.gitlab.com/ee/user/gitlab_com/index.html#delayed-project-deletion):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/396996).
Groups & Projects[Custom value streams for project-level value stream analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/):
> To improve the visibility into the complete workstream, we are adding to the project-level Value Stream Analytics (VSA) the [Overview stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics) and the option to [create custom value streams](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-custom-stages).
>
> Until now, these features were only available at the group-level VSA only.
Value Stream Management[New stage events for custom Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-custom-stages):
> 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.
Value Stream Management[Mirror specific branches only](https://docs.gitlab.com/ee/user/project/repository/mirror/#mirror-specific-branches):
> 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.
Source Code Management[Workspaces available in Beta for public projects](https://docs.gitlab.com/ee/user/workspace/index.html):
> 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](https://docs.gitlab.com/ee/user/workspace/#prerequisites) 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](https://docs.gitlab.com/ee/user/workspace/index.html) and let us know what you think in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031).
Workspaces[Token rotation API](https://docs.gitlab.com/ee/security/token_overview.html):
> 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.
System Access[Rate limit for unauthenticated users of the Projects List API](https://docs.gitlab.com/ee/administration/settings/rate_limit_on_projects_api.html):
> 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](https://about.gitlab.com/pricing/).
Groups & Projects[Self-managed GitLab uses two database connections](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections) (self-managed only):
> 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](https://gitlab.com/groups/gitlab-org/-/epics/7509) 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.
Cell[Option to disable followers](https://docs.gitlab.com/ee/user/profile/#disable-following-and-being-followed-by-other-users):
> 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.
System Access, User Profile[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - Updates to GitLab 16.0 also update cert-manager to version 1.11.x. This cert-manager update includes breaking changes you must
> [read before upgrading](https://cert-manager.io/docs/release-notes/release-notes-1.10/#breaking-changes-you-must-read-this-before-you-upgrade).
> These changes include a change to container names that was best done during a major release of GitLab. To see details of updated features, see the
> [releases notes for cert-manager 1.11](https://cert-manager.io/docs/release-notes/release-notes-1.11).
> - PostgreSQL 12 is no longer supported. The minimum required version is PostgreSQL 13, and support for PostgreSQL 14 is added.
> New chart installs of GitLab include PostgreSQL 14 by default, and upgrades must follow the steps for
> [upgrading the bundled PostgreSQL version](https://docs.gitlab.com/charts/installation/database_upgrade.html).
> - Updates to GitLab 16.0 include an update to the Redis subchart to version 16.13.2, including Redis 6.2.7.
> - We have removed the bundled Grafana chart. For more information, see
> [removal of the bundled Grafana Helm chart](https://docs.gitlab.com/ee/update/removals.html#bundled-grafana-helm-chart) on our removals page.
> If you use the bundled Grafana, you must switch to the [newer chart version from Grafana Labs](https://artifacthub.io/packages/helm/grafana/grafana)
> or a Grafana Operator from a trusted provider.
> - GitLab 16.0 includes
> [registry services details for webservice and Sidekiq](https://docs.gitlab.com/charts/charts/globals.html#configure-registry-settings)
> in the `global.registry.*` configuration for simplification because the values are present in both. You can keep the old behavior with an override.
> - The [minimum supported Helm version](https://docs.gitlab.com/charts/installation/tools.html#helm) is 3.5.2.
> - The GitLab Runner default version is now Ubuntu 22.04.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - PostgreSQL 12 is no longer supported. The minimum required version is PostgreSQL 13. Users of the packaged PostgreSQL 12 must
> [perform a database upgrade](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) before installing GitLab
> 16.0.
> - The new base OS for the Omnibus GitLab docker images is Ubuntu 22.04.
> - GitLab 16.0 disables older telemetry endpoints for Consul, which were deprecated in Consul 1.9. This allows us to
> [update Consul to newer versions](https://developer.hashicorp.com/consul/docs/v1.12.x/agent/config/config-files#telemetry-parameters).
> - GitLab 16.0 includes packages for Red Hat Enterprise Linux (RHEL) 9 and compatible distributions.
> - GitLab 16.0 includes [Mattermost 7.10](https://mattermost.com/) with [security updates](https://mattermost.com/security-updates/). An upgrade from earlier versions is recommended.
Omnibus Package[Additional Registration Features available to Free users](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program) (self-managed only):
> GitLab Free customers with a self-managed instance running GitLab Enterprise Edition can now access five more paid features under the [Registration Features](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program) program:
>
> - [Password complexity policy](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#password-complexity-requirements)
> - [Description change history](https://docs.gitlab.com/ee/user/discussions/index.html#view-description-change-history)
> - [Issue board configuration](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards)
> - [Maintenance mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html)
> - [Coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#coverage-guided-fuzz-testing)
>
> To get access to these features, register with GitLab and send us activity data through [Service Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#enable-registration-features).
Product Analytics[Import collaborators as an additional item to import](https://docs.gitlab.com/ee/user/project/import/github.html#select-additional-items-to-import):
> In GitLab 15.10, we started mapping GitHub repository collaborators as GitLab project members during GitHub project imports. We received
> [feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/398154) 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](https://docs.gitlab.com/ee/user/project/import/github.html#select-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](https://docs.gitlab.com/ee/user/project/import/github.html#collaborators-members). Only
> direct collaborators are imported. Outside collaborators are never imported.
Importers[Filter GitHub repositories to import](https://docs.gitlab.com/ee/user/project/import/github.html#filter-repositories-list):
> 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:
>
> - **Owner**, to list repositories you own.
> - **Collaborator**, to list repositories you collaborate on.
> - **GitHub organization**, to list repositories that belong to GitHub organizations.
>
> On the **Organization** tab, you can further narrow down your search and choose a specific organization and list only repositories belonging
> to that organization.
Importers[Mark to-do items completed by other group or project owners Done](https://docs.gitlab.com/ee/user/todos.html#actions-that-mark-a-to-do-item-as-done):
> 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.
Groups & Projects, User Management[Opt in to a new navigation experience](https://docs.gitlab.com/ee/tutorials/left_sidebar/index.html):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/409005). 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.
Navigation & Settings[Limit session length for users](https://docs.gitlab.com/ee/user/profile/#session-duration) (self-managed only):
> 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.
System Access[Authenticate with Jira personal access tokens](https://docs.gitlab.com/ee/integration/jira/configure.html#configure-the-integration):
> Previously, you could only authenticate the [Jira issue integration](https://docs.gitlab.com/ee/integration/jira/configure.html) with a Jira username
> and password.
>
> Now you can use a [Jira personal access token](https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html) 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.
Integrations[Display message when deploy freeze is active](https://docs.gitlab.com/ee/user/project/releases/index.html#prevent-unintentional-releases-by-setting-a-deploy-freeze):
> 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.
Environment Management[Add or resolve to-do items on tasks, objectives, and key results](https://docs.gitlab.com/ee/user/todos.html):
> We know that GitLab [To-Do List](https://docs.gitlab.com/ee/user/todos.html) 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.
Team Planning[GitLab Pages unique subdomains](https://docs.gitlab.com/ee/user/project/pages/):
> 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.
Pages[Add emoji reactions on tasks, objectives and key results](https://docs.gitlab.com/ee/user/award_emojis.html):
> 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.
Team Planning[Change work item type from quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html#issues-merge-requests-and-epics):
> With this additional quick action, you can now convert key results to objectives.
Portfolio Management[Pick custom colors for labels](https://docs.gitlab.com/ee/user/project/labels.html):
> 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.
Team Planning[Reorder child records for tasks, objectives and key results](https://docs.gitlab.com/ee/user/okrs.html#reorder-objective-and-key-result-children):
> If you're a user of [tasks](https://docs.gitlab.com/ee/user/tasks.html) 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.
Portfolio Management[Comment templates](https://docs.gitlab.com/ee/user/profile/comment_templates.html):
> 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!
Code Review Workflow, Team Planning[Update your fork from the GitLab UI](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#update-your-fork):
> 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.
Source Code Management[New Web IDE experience now generally available](https://docs.gitlab.com/ee/user/project/web_ide/):
> 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.
Web IDE[Real-time merge request updates](https://docs.gitlab.com/ee/user/project/merge_requests/):
> 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](https://gitlab.com/groups/gitlab-org/-/epics/1812) in merge requests, so follow along for updates.
Code Review Workflow[Create an instance runner in the Admin Area as a user](https://docs.gitlab.com/ee/ci/runners/register_runner.html):
> 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.
Runner Fleet[Trigger job mirror status of downstream pipeline when cancelled](https://docs.gitlab.com/ee/ci/yaml/#triggerstrategy):
> 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.
Pipeline Composition[CI/CD components](https://docs.gitlab.com/ee/ci/components/):
> 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`](https://docs.gitlab.com/ee/ci/yaml/includes.html#define-inputs-for-configuration-added-with-include-beta) 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.
Pipeline Composition[REST API endpoint to create a runner](https://docs.gitlab.com/ee/api/users.html#create-a-ci-runner):
> 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.
Runner Fleet[Per-cache fallback cache keys in CI/CD pipelines](https://docs.gitlab.com/ee/ci/caching/index.html#per-cache-fallback-keys):
> 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.
Pipeline Composition[Create a group runner as a user](https://docs.gitlab.com/ee/ci/runners/register_runner.html#for-a-group-runner):
> 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.
Runner Fleet[Configurable maximum number of included CI/CD configuration files](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#maximum-includes) (self-managed only):
> 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.
Pipeline Composition[Create project runners as a user](https://docs.gitlab.com/ee/ci/runners/register_runner.html#for-a-project-runner):
> 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.
Runner Fleet[Rate Limit for the `projects/:id/jobs` API endpoint reduced](https://docs.gitlab.com/ee/security/rate_limits.html#project-jobs-api-endpoint):
> Previously, 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.
Continuous Integration (CI)[GitLab Runner 16.0](https://docs.gitlab.com/runner):
> 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.
>
> #### What's new:
>
> - [GitLab Runner autoscaling plugin for Google Compute Engine - Experiment](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29217)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/16-0-stable/CHANGELOG.md)
GitLab Runner Core[Import Maven/Gradle 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 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.
Package Registry[Download packages from the Maven Registry with Scala](https://docs.gitlab.com/ee/user/packages/maven_repository/#install-a-package):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/408479) if you are interested in adding support for publishing.
Package Registry[SAST analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab SAST includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.0 release milestone:
>
> - The Semgrep-based analyzer includes updated [GitLab-managed scanning rules](https://gitlab.com/gitlab-org/security-products/sast-rules). See the [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v423) for further details. We've updated the rules to:
> - Update OWASP mappings to show that they're based on the 2017 OWASP Top Ten. Thanks to [`@artem-fedorov`](https://gitlab.com/artem-fedorov) for this [community contribution](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/196).
> - Handle additional cases in the `PyYAML.load` rule. Thanks to [`@stevep-arm`](https://gitlab.com/stevep-arm) for this [community contribution](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/237).
> - Significantly improve the descriptions and guidance for C rules based on revisions from the GitLab Vulnerability Research team.
> - Add support for [scanning Scala code](#faster-easier-scala-scanning-in-sast).
> - The Flawfinder-based analyzer now supports [passing the `--neverignore` flag](https://docs.gitlab.com/ee/user/application_security/sast/#security-scanner-configuration) to disregard "ignore" directives in comments. See the [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/blob/master/CHANGELOG.md#v401) for further details.
> - The KICS-based analyzer is updated to KICS version 1.7.0. See the [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v401) for further details.
> - The MobSF-based analyzer now supports multiple modules and projects, which resolves several bug reports. See the [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v401) for further details.
>
> Also, [as previously announced](https://docs.gitlab.com/ee/update/deprecations.html#secure-analyzers-major-version-update), we increased the major version number of each analyzer as part of GitLab 16.0.
>
> 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)) 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](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version).
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2023/04/22/gitlab-15-11-released/#static-analysis-analyzer-updates).
SAST[Secret Detection updates](https://docs.gitlab.com/ee/user/application_security/secret_detection/):
> We regularly release updates to the GitLab Secret Detection analyzer. During the GitLab 16.0 milestone, we:
>
> - Added [GitLab-managed detection rules](https://docs.gitlab.com/ee/user/application_security/secret_detection/#detected-secrets) for:
> - Access tokens for the Meta, Oculus, and Instagram APIs.
> - Tokens for the Segment Public API.
> - Updated the Gitleaks scanning engine to version 8.16.3.
> - [Fixed a bug](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/212) that prevented scanning when a repository had only a single commit.
> - Incremented the analyzer major version to `5`, [as previously announced](https://docs.gitlab.com/ee/update/deprecations.html#secure-analyzers-major-version-update).
>
> See the [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v501) for further details.
>
> If you [use the GitLab-managed Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#enable-secret-detection) ([`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/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](https://docs.gitlab.com/ee/user/application_security/secret_detection/#pinning-to-specific-analyzer-version).
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2023/04/22/gitlab-15-11-released/#static-analysis-analyzer-updates).
Secret Detection[Faster, easier Scala scanning in SAST](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> 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](https://about.gitlab.com/releases/2022/04/22/gitlab-14-10-released/#faster-easier-java-scanning-in-sast).
> As with the other languages we have [transitioned to Semgrep-based scanning](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#transition-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](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)), 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](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)) 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](https://gitlab.com/gitlab-org/gitlab/-/issues/412060) 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](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug&add_related_issue=362958&issue[title]=Feedback%20on%20SAST%20Semgrep%20Scala%20support&issue[description]=%2Flabel%20~%22group%3A%3Astatic%20analysis%22), we'll be glad to help.
SAST[Placeholder for issue description in Service Desk automated replies](https://docs.gitlab.com/ee/user/project/service_desk/#new-note-email):
> 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.
Service Desk